Replies: 6 comments 14 replies
-
|
Example of expected result:
|
Beta Was this translation helpful? Give feedback.
-
|
I think I might agree with this, with a small added detail: The default should be exactly what you propose, BUT it should still remain easy for the user to override the default. Or in other words, when the user fails to specify how they want color to be output, try to be "smart" about it using the |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps something like this: Current implementation: print_in_color() {
local color="$1"
shift
if [[ -z ${NO_COLOR+x} ]]; then
printf "$color%b\e[0m\n" "$*"
else
printf "%b\n" "$*"
fi
}New implementation: print_color_always() {
local color="$1"
shift
printf "$color%b\e[0m\n" "$*"
}
print_newline() {
printf "%b\n" "$*"
}
if [ "${NO_COLOR}" == "1" ]; then
print_in_color() {
shift
print_newline "$@"
}
elif [ "${NO_COLOR}" == "0" ]; then
print_in_color() {
print_color_always "$@"
}
elif [ -t 1 ]; then
print_in_color() {
print_color_always "$@"
}
else
print_in_color() {
shift
print_newline "$@"
}
fi |
Beta Was this translation helpful? Give feedback.
-
|
I am not convinced at all. Here is why:
That said - if there is a way to slightly (read: "while keeping it simple") modify the bundled colors library in order to make it easier to enable this behavior - I am for it. |
Beta Was this translation helpful? Give feedback.
-
|
for what it's worth, point 5 is addressed in my above suggestion. it checks env variables first and does whatever the environment says. if no env variables are specified, then it autodetects. also, i don't think i'd implement it exactly the way i suggested above -- that was just a quick brain dump. maybe i can find some time in the next weeks / months to submit a PR that abides by the "slight" change requirement. |
Beta Was this translation helpful? Give feedback.
-
|
eh, i read the NO_COLOR standard a little more closely and decided that it's not feasible to do this generically for everyone. i think we should leave the color functionality alone. that said, because i read the spec a little more closely, i have a bugfix for you 😁 #610 though... arguably more of a nitpick than a bugfix. |
Beta Was this translation helpful? Give feedback.
-
|
after looking at it in-depth, i have come to the conclusion that script developers should implement their own that said, this would be another good "recipe" one could add to the wiki. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, well - printing things in color is quite a basic ability that I was hoping would be at a better "standards" state by now. I guess we can easily do an alternative colors library that explicitly does NOT follow |
Beta Was this translation helpful? Give feedback.
-
|
Here is my proposal:
print_in_color() {
local color="$1"
shift
if use_color; then
printf "$color%b\e[0m\n" "$*"
else
printf "%b\n" "$*"
fi
}
use_color() {
if [[ -n $COLOR ]]; then
case $COLOR in
always) return 0 ;;
never) return 1 ;;
*) [[ -t 1 ]] && return 0 || return 1 ;; # anything else is "auto"
esac
elif [[ "${NO_COLOR:-}" == "" ]]; then
return 0
else
return 1
fi
}
red() { print_in_color "\e[31m" "$*"; }
# ... more color functions, as in the original libraryThis allows the developer to choose what to use, and even to just leave it for the user to decide. Thoughts? |
Beta Was this translation helpful? Give feedback.
-
Ah. Right, I was working with the released version. |
Beta Was this translation helpful? Give feedback.
-
|
See #611 with these changes. |
Beta Was this translation helpful? Give feedback.
-
|
I think the |
Beta Was this translation helpful? Give feedback.
-
|
👍 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Its settled then. Version 1.2.9 will have this option. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
🗣️ UPDATE
This discussion was "solved" in #611!
original post
Colorized output is pretty neat in interactive sessions. But when we want to use pipes or redirection, those ANSI escape codes are pollution.
There's a POSIX-compliant way to check if a script is being executed in an interactive session
test -t.Here's the description from the official specification
I usually use the bash version:
It would be cool if the
colors.shfrom the bashly standard library was smart enough to check if the output is going to a terminal or not (pipe/redirection).I tried adding the
[[ -t 1 ]]logic in theprint_in_colorfunction, but soon realized that when it's called as a consequence ofecho "before $(red this is red) after", the stdout is never a terminal (in other words:[[ -t 1 ]]is always false).The solution I've found was adding this to my
src/initialize.sh:and it works pretty well.
It also works if we put that line in the top-level scope of
colors.sh, which would make the solution available for everyone with no need to tweak theinitialize.sh.What do you think?
Beta Was this translation helpful? Give feedback.
All reactions