> Why not just set $TERM to dumb or xterm without color support? Or change all color definitions in the terminal to print the same color?
> The terminal is capable of color and should be able to print color when instructed. NO_COLOR is a hint to the software running in the terminal to suppress addition of color, not to the terminal to prevent any color from being shown.
I have to admit I don't really get this. I personally like colorized output, and I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely.
I respect others like no color (and there's already a solution per that, above), but I don't quite get the desire to have just some color (prompts but not applications). Can someone with this opinion explain their rationale?
Normally I wouldn't care,
-- individual preferences are like opinions and everyone is entitled to their own -- but this imposes work on every developer/application. There's certainly ways to implement this that minimize impact, but it's still a non-zero up-front and ongoing maintenance/testing cost.
> I have to admit I don't really get this. I personally like colorized output, and I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely.
There's a few programs i use where the colours were clearly chosen to work on a dark theme terminal. I use a light theme terminal, and they're illegible.
I suppose the real problem here is that the output is tagged with physical colour, rather than some kind of semantic label which could be mapped to a colour in terminal configuration. But it's probably too late to do anything about that.
Don't most terminal emulators allow you to set your own color palette? So what would show up as yellow text on a normal black background, you could change to show up as maybe as gold? Obviously it would mess with the meaning behind why the developer chose that particular color (like red errors, yellow or orange warnings) but I'm sure you'd get used to it.
Guilty [1]. But it's really hard to handle both light and dark color themes! On a dark terminal you're probably more likely to use the "Bright" variants when using the default 16 color palette, but then you'll have less contrast in a light theme. Some color schemes intentionally invert the "bright" colors and makes them darker for a light colored scheme. This is what Gruvbox [2] does, but most other palettes don't. I also have an issue with Solarized which makes some of the Bright colors almost exactly the same as the foreground or background, which can make text printed in certain colors seem invisible.
I've used ANSI codes to invert colors (which works pretty well for highlighting), and dim colors, but those can't solve everything.
The physical colors are what the terminal configuration maps to. At least, modern terminals that I've used since the DOS era. Even back then, I had a tiny utility that I used to set the EGA palette for different text-mode programs. Amberscale tones on a deep low-saturation blue was one of my favorites.
Obviously won't help if you're using a teletype or punched cards or something like that.
A lot of these tools assume that you’re using a dark theme. If you’re using a white-ish background (even worse somewhat beige, like I do), things like text highlighted in yellow become invisible.
Also, some of these tools don’t detect when they are run in a non interactive shell and will continue to write color codes when piped.
A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection
> A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection
Is checking an environment variable that much easier than an isatty(3) call? I'm concerned that if this becomes widely implemented, developers will try using it as a poor substitute for isatty.
ANSI terminals only offer 8 colours (extended to 16 with some tricks) based on grey-on-black screens of old. They, by default, have a certain set of features (like which colour contrasts which colour). Basically, it's a very limited palette, and it's up to the theme to maintain all the properties and features that hold between original colours.
While developers can make use of more than 8/16 colours today, I find that extremely rare, and if a colour display for an app does not work on your theme, it's either an app problem in that it wouldn't work well in any terminal, or a theme problem.
If it's an app issue, what makes you believe an author would rather implement NO_COLOR instead of fixing colour choices they made?
Implementing a flag like COLOR=light|dark|none puts the onus on application developers to interpret the user's configuration.
I think it would be more reasonable to define a standard set of environment variables based on semantics that can then be used explicitly by scripts and programs. Like CL_WARN=(code for red) CL_HILIGHT=(code for yellow) CL_OPTIONAL=(code for gray). This would make it very easy on script developers, who would only need to use these variables instead of their hard-coded ones.
Agreed. I'm guilty of scratching my own itch and inferring dark themes and interactive sessions, but it's nice to build things in a manner that may allow for a better integration with something else.
> I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely.
The main use case for this is that there are tools that use ANSI color libraries and don't handle non-colorization in non-TTY contexts. So what ends up happening is a user of said tool pipes its output to a log file and since ANSI escape codes are in-band, the log file becomes an unreadable mess. NO_COLOR provides a way for the library to give control over colorization to the user, even if the tool consuming the library hard codes colorization logic.
This does not make any sense at all. The intent is to fix programs that don't handle non-colorization in non-TTY context, and the solution is to do so by patching them by responding to an environment variable or command-line option to explicitly request no colors. Why not just fix them to handle non-colorization in non-TTY context correctly?
This is also in opposition to the motivation explicitly laid out in the website itself.
>An increasing number of command-line software programs output text with ANSI color escape codes by default. While some developers and users obviously prefer seeing these colors, some users don’t. Unfortunately, every new piece of software seems to have a different way of disabling colored text output and some software has no way at all.
Clearly, the motivation laid out here is in fact to provide a standard mechanism to disable the colors seen by the user on the terminal. Not to disable coloring when output is being redirected.
I'm not at all disagreeing with the premise, but I'd like to point out that having the ANSI escape codes written to the (in this example) log file shouldn't be that much of a problem. Many tools support them (though I admit that sometimes it's not default behavior). For example, I often use `less -R` for this purpose.
> I respect others like no color (and there's already a solution per that, above), but I don't quite get the desire to have just some color (prompts but not applications). Can someone with this opinion explain their rationale?
The output is sometimes 'too busy' and the colours are of arbitrary values which may mean any number of things, and if you don't what they mean they're just noise.
Further the same thing may be signified by different colours by different programs (editor A may have, e.g., variables as colour X, but editor B may have variables as colour Y, and the pager as colour Z).
Perhaps if I was a coder, using one environment/editor/IDE, I could learn things. But as a sysadmin (whose been doing this for a few decades: Linux, BSD, Solaris, IRIX), I have never found colour† useful since I'm doing things in all sorts of contexts in the course of a day, and have never really found a need.
I imagine if you're hopping on and of dozens of different systems daily, it might help to have the host and username pop out at you even if everything else is greyscale.
It's sort of how I always set VMs to have a dark grey flat background. Makes it easier to see at a glance whether you're in a fullscreen VM or the host system.
If you start using color, you need to consider accessibility. What if you use some combinations of foreground and background inadvertently that renders it unreadable. Also, there's no guarantee color pallets will be the same.
There also needs to be a NO_EMOJI flag. I'm tired of having random garbage glyphs show up because I'm not using the latest electron based terminal that uses mono-spaced web-fonts.
> I'm tired of having random garbage glyphs show up because I'm not using the latest electron based terminal that uses mono-spaced web-fonts.
It doesn't take a Electron based terminal. iTerm2 on OS X supports emoji, and Terminal.app mostly does. Terminator on Linux supports them. (& which is based on VTE, so I sort of presume all VTE-based terminals do.) None of which are Electron based. (& I can understand not wanting that.)
(Not to imply that a NO_EMOJI might have other merits.)
The noto emoji font is usually all you need, just having it installed is often enough for them to show if your terminal emulator supports fallback fonts (I think st doesn't, but most do).
I support the idea of a NO_EMOJI env var anyway. I think theming should be left up to the user in nearly all cases and we shouldn't have colors or emoji forced on us. Devs could have something like alt text to show when emoji aren't there for cases where they're showing a meaning that the text doesn't.
I still prefer color for matching quotes in editors. And they're useful in tui programs like cmus and tmux. And git add -p. That's about it for me though. I don't find it helpful in the output of package managers, ffmpeg, etc. It's clown vomit that makes things even harder to read imo.
This env var wasn't a universal enough solution the last time I tried it, so I just set almost all my term colors except red (for the quote matching) to black.
On the whole I'm really put off by the aesthetics of programming. The default still seems to be very "gamer": dark mode, neon everything—I can practically smell the Mtn Dew through my screen sometimes.
>On the whole I'm really put off by the aesthetics of programming. The default still seems to be very "gamer": dark mode, neon everything—I can practically smell the Mtn Dew through my screen sometimes.
Oh, come on... Look at the original terminals from the old days. Dark background with green or amber text. Dark terminals are the normal thing, nothing to do with gamers. My guess is it was less power to only light up the text parts instead of the inverse. Light themes, on a computer, seem unnatural in the way they force as much light as possible on. They're trying to emulate paper, which is white by default, but I don't think that should be considered normal on a computer.
I like the colors from some commands (like ls) but I think everyone has had some experience with a command that has very bad colors, making some important information hard to read or just being really ugly. So the variable also provides a universal way to run any individual command without color if desired.
>The default still seems to be very "gamer": dark mode, neon everything
Dark mode is common but I've seen dull tones predominate for normal text over the last decade at least.
> I don't find it helpful in the output of package managers, ffmpeg, etc. It's clown vomit that makes things even harder to read imo.
IMO in the case of package managers it actually makes it more readable. For example zypper (in openSUSE) uses a colored heading to group the packages it is going to install/upgrade/remove/etc and it uses a color for the first letter of each package, both making it very simple to quickly scan the packages that are going to be installed or affected whenever there is a big list of them - e.g. i can quickly skip all the libraries (since they begin with "l").
Personally, I use NO_COLOR or other techniques to disable color when I'm logging output or using a CI/CD pipeline. Color codes tend to create all kinds of garbage in your logs otherwise.
I like color in my CI logs because it makes it easier for a human to spot various information.
Obviously sometimes you might want to grep your logs and then color sequences might be annoying. I guess there is a command line tool / sed / awk oneliner to remove them. Unix filters are from the 1970s after all.
The question is just what is the tool. I'd guess SO knows... But it's Sunday morning and I am on my phone not motivated to work :)
> I don't quite get the desire to have just some color (prompts but not applications). Can someone with this opinion explain their rationale?
The more sparingly you use colour, the more effective it is as a means to highlight important information. Different users think different information is important.
I'm not sure how widespread it is but I work in the mining industry and I've seen a trend on newer installations towards keeping the general appearance of the entire interface to a couple of modestly contrasting neutral greys. Only parts of the plant which require operator attention are shown in colour (I think plant that's not in the normal automatic operation mode was yellow and alarms were red). The information's still all there and easy to read if the operator wants to, but it's not screaming for your attention unless it actually needs it.
Compare this with the usual visual confetti of brightly flashing colours that a SCADA system devolves into, especially after a few years when a lot of 'important new features' have been added 'which the operator needs to see'.
You've never had a program ANSI puke into a sink that expressly is not a terminal and expects only plain text -- for example, an Emacs buffer. Tired of setting magic flags on Maven to suppress color output when I do M-x compile, for instance.
I like colour, but can easily empathise and visualize that I may like colour in applications I've configured, but found it obtrusive in something that vomits inconsistent, garish, distracting coloured output. So while I would not necessarily use this environment wetting, I can understand why some would treasure predictability and consistency.
Note btw that one might have a wildly different perspective as e.G. Developer using a few tools on their own controlled desktop a lot, vs e.G. a sysadmin constantly jumping between large number of tools on large number of systems. As such, having a simple variable to shut up all the apps on all the servers may be quite handy.
The default colorscheme is extremely bad and if you use Vim to open log files, the comments are unreadable because they're colored as dark blue on a black background. Most of the other colors are unreadable as well. The widespread usage of PuTTY in my organization is the reason I have never written scripts or programs with colors, even though colors would help a lot of people differentiate between benign, warning, and error messages.
> I have to admit I don't really get this. I personally like colorized output, and I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely.
Colorized output really sucks when the output is displayed in a terminal that doesn’t support it. Visual Studio’s build output, online build terminals like CircleCI, log viewers, …
(Unsure if the ones I list above actually do have an issue with colors, but absolutely sure that I have seen it many times.)
CI pipelines - I need clean readable output constantly, and having random escape codes all over the output just garbages up the flow into messages nobody reads. Setting NO_COLOR=1 once in the pipeline fixes 80% of output issues.
Would it be nice if every pipeline tool supported the gambit of colors? Maybe, maybe I wouldn't care then. But as it is, more often than not, your cute colors just garbage up my build output.
Why focus on imposing additional work on developers, rather than users (which, by the definition, is much wider audience) having to workaround hard-coded behavior? Adding color support to cli tools is an additional work for developers in the first place
The answer is super easy: I want JSON to be shown with syntax highlight but when I pipe it elsewhere I want porcelain output. $NO_COLOR is an additional indicator that the output might need further processing and it’s not for human consumption (in a terminal)
What you might be missing is that “color” on the CLI is actually extra characters before and after a colored word. If the viewer does not interpret them (for example a web UI), they will just be extra characters. This is akin to printing `<strong>8000 bytes</strong>` and expect it to be rendered correctly everywhere it’s shown.
1. I want to see color output in some commands, but not all of them (in some cases like with grep/ag it is very useful, in some cases colors are not useful or even makes it harder to read command output). NO_COLOR allows me to control output per-command by creating aliases 'env NO_COLOR=1 command'
2. Some color-using CLI tools assume white-ish background and actively use dark blue which is hard to see on a black background.
There can be situations where the output intended for an ANSI terminal is shown as a raw text, including the color control sequences. Being able to switch off color should help with these situations.
Some terminals have picked their default ls colors so bad that some entries are almost unreadable. Dark blue on black etc. Forced me to configure the LS_COLORS.
my vision is degrading, and I have never seen a colored output where every color worked on the background color, it's really irritating with dark red error messages on black backgrounds for example because error messages are the kind of thing you really want to read and then I either need to zoom in a lot or in some cases copy the text of the message and put it into a text editor where I can read it.
One case I can think of is parsing output without the intermittent hidden unicode codes to change the color. Changing terminal settings won’t change that.
Most software that I use regularly which does color output does it well, and it's probably a net benefit for me.
But sometimes software that I use irregularly, or only in specific circumstances, does it poorly, and it's a real pita. I've had occasions where I missed entire pieces of output because they rendered as the background color for some reason. So for those cases it'd be nice to have a universal switch, so to speak, to just turn it off.
I also get that for some people it's just an aesthetic choice... I don't think color is _that_ helpful that someone would be impaired by not having it.
All that said, this proposal reminds me of that one xkcd with the 13 competing standards.
I'm starting to be of the mind that environment variables in general are an anti-pattern. They have arbitrary scope, their lifetime is not clear, and they are not easily composable. This was not something that bothered me so acutely until I started using declarative config with NixOS to configure my system, and found environment variables to be a big wart on this.
Environment variables are fine when used for things that usually don't change once they're set. For example, XDG_CONFIG_HOME or GOPATH. They are, however, absolutely awful when used to configure values that will probably change inside a session. A good example is BEMENU_OPTS from the bemenu program, which is used to change colors, font etc. Should I relogin into my session just to make a program use dark mode colors?
In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts or overridden on the command line before executing a command, which is extremely annoying.
> In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts
Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. It's no different than setting up an alias, and I'd rather use a wrapper script or alias than have to remember how the app is configured, or search my history for the correct invocation.
In fact, environment variables are a very flexible way of configuring an app. They're generic, work the same across apps (no worries about the various ways of specifying flags), avoid the need for a custom configuration file, you can have multiple .env files and load them with env(1), etc.
I'm a big fan of following the 12factor[1] approach.
This also misses options such as letting COLOR=1 force colours which would be nice when I want to redirect "human" output to a file without bothering to set up a TTY.
It’s a real pain when two things use the same name. Spent ages trying to debug an issue and it ended up being the distro I was using was setting “VERSION” which is generic enough that something else happened to be using it as well..
I think this is a fine idea but I wonder about this part:
"... should check for the presence of a NO_COLOR environment variable that, when present (regardless of its value), prevents the addition of ANSI color ..."
How common is this behavior ?
That is, the presence of the env var regardless of its value trips the conditional ?
That seems like asking for trouble / confusion ... especially since there is a very well understood practice of setting 0/1 false/true for settings like this.
Is this commonly done and I have just never noticed it ?
One question this leaves me with is regarding other ANSI escapes. Would a user with NO_COLOR be okay with bold, invert, italic, underline, or other effects? I’m happy to add support for NO_COLOR to the tool I maintain, but I think this proposal should be more clear in this regard.
I would assume that COLOR implies that only color escapes should be disabled, but the description also mentions “plain” output.
This problem was solved using the TERM environment variable, and it will just work when people use terminfo (and libraries that use it, such as ncurses).
The problem is when people use explicit escape codes in their code rather than using libraries that solved this problem all the way back in the 80's.
Yes, I'm somewhat grumpy about this because far too many times I have found log files filled with escape codes, or colours that are absolutely unreadable when using a terminal with white background.
Yeah this is the earlier and better standard (more powerful and more precedent). The NO_COLOR guy should have dropped it as soon as people told him about this but now we have a stupid competing standards situation.
If you support NO_COLOR you're making things worse.
While this is a good standard, I often find myself just doing `somecommand | cat` whenever I want to get rid of colors. Usually they're disabled when outputting to a non-tty device.
Without understanding the minutiae of this, couldn’t someone just write a program that we can pipe any output to, which strips colour commands from its input before writing it back out? Does such a program already exist? That wouldn’t require every program to add support for an environment variable.
By itself, less will prevent any control sequences (including colours) from actually being sent to the terminal, but most distros seem to have -R set on it by default these days. If you unset -R it'll do exactly that.
Readit News
> The terminal is capable of color and should be able to print color when instructed. NO_COLOR is a hint to the software running in the terminal to suppress addition of color, not to the terminal to prevent any color from being shown.
I have to admit I don't really get this. I personally like colorized output, and I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely.
I respect others like no color (and there's already a solution per that, above), but I don't quite get the desire to have just some color (prompts but not applications). Can someone with this opinion explain their rationale?
Normally I wouldn't care, -- individual preferences are like opinions and everyone is entitled to their own -- but this imposes work on every developer/application. There's certainly ways to implement this that minimize impact, but it's still a non-zero up-front and ongoing maintenance/testing cost.
There's a few programs i use where the colours were clearly chosen to work on a dark theme terminal. I use a light theme terminal, and they're illegible.
I suppose the real problem here is that the output is tagged with physical colour, rather than some kind of semantic label which could be mapped to a colour in terminal configuration. But it's probably too late to do anything about that.
I've used ANSI codes to invert colors (which works pretty well for highlighting), and dim colors, but those can't solve everything.
[1]: https://github.com/PaulJuliusMartinez/jless/issues/4 [2]: https://github.com/morhetz/gruvbox
Obviously won't help if you're using a teletype or punched cards or something like that.
Also, some of these tools don’t detect when they are run in a non interactive shell and will continue to write color codes when piped.
A NO_COLOR flag is not perfect but better than nothing and easier to implement than theme or interactivity detection
Is checking an environment variable that much easier than an isatty(3) call? I'm concerned that if this becomes widely implemented, developers will try using it as a poor substitute for isatty.
While developers can make use of more than 8/16 colours today, I find that extremely rare, and if a colour display for an app does not work on your theme, it's either an app problem in that it wouldn't work well in any terminal, or a theme problem.
If it's an app issue, what makes you believe an author would rather implement NO_COLOR instead of fixing colour choices they made?
I think it would be more reasonable to define a standard set of environment variables based on semantics that can then be used explicitly by scripts and programs. Like CL_WARN=(code for red) CL_HILIGHT=(code for yellow) CL_OPTIONAL=(code for gray). This would make it very easy on script developers, who would only need to use these variables instead of their hard-coded ones.
The main use case for this is that there are tools that use ANSI color libraries and don't handle non-colorization in non-TTY contexts. So what ends up happening is a user of said tool pipes its output to a log file and since ANSI escape codes are in-band, the log file becomes an unreadable mess. NO_COLOR provides a way for the library to give control over colorization to the user, even if the tool consuming the library hard codes colorization logic.
This is also in opposition to the motivation explicitly laid out in the website itself.
>An increasing number of command-line software programs output text with ANSI color escape codes by default. While some developers and users obviously prefer seeing these colors, some users don’t. Unfortunately, every new piece of software seems to have a different way of disabling colored text output and some software has no way at all.
Clearly, the motivation laid out here is in fact to provide a standard mechanism to disable the colors seen by the user on the terminal. Not to disable coloring when output is being redirected.
The output is sometimes 'too busy' and the colours are of arbitrary values which may mean any number of things, and if you don't what they mean they're just noise.
Further the same thing may be signified by different colours by different programs (editor A may have, e.g., variables as colour X, but editor B may have variables as colour Y, and the pager as colour Z).
Perhaps if I was a coder, using one environment/editor/IDE, I could learn things. But as a sysadmin (whose been doing this for a few decades: Linux, BSD, Solaris, IRIX), I have never found colour† useful since I'm doing things in all sorts of contexts in the course of a day, and have never really found a need.
† Besides the prompt perhaps.
It's sort of how I always set VMs to have a dark grey flat background. Makes it easier to see at a glance whether you're in a fullscreen VM or the host system.
There also needs to be a NO_EMOJI flag. I'm tired of having random garbage glyphs show up because I'm not using the latest electron based terminal that uses mono-spaced web-fonts.
It doesn't take a Electron based terminal. iTerm2 on OS X supports emoji, and Terminal.app mostly does. Terminator on Linux supports them. (& which is based on VTE, so I sort of presume all VTE-based terminals do.) None of which are Electron based. (& I can understand not wanting that.)
(Not to imply that a NO_EMOJI might have other merits.)
I support the idea of a NO_EMOJI env var anyway. I think theming should be left up to the user in nearly all cases and we shouldn't have colors or emoji forced on us. Devs could have something like alt text to show when emoji aren't there for cases where they're showing a meaning that the text doesn't.
This env var wasn't a universal enough solution the last time I tried it, so I just set almost all my term colors except red (for the quote matching) to black.
On the whole I'm really put off by the aesthetics of programming. The default still seems to be very "gamer": dark mode, neon everything—I can practically smell the Mtn Dew through my screen sometimes.
Oh, come on... Look at the original terminals from the old days. Dark background with green or amber text. Dark terminals are the normal thing, nothing to do with gamers. My guess is it was less power to only light up the text parts instead of the inverse. Light themes, on a computer, seem unnatural in the way they force as much light as possible on. They're trying to emulate paper, which is white by default, but I don't think that should be considered normal on a computer.
>The default still seems to be very "gamer": dark mode, neon everything
Dark mode is common but I've seen dull tones predominate for normal text over the last decade at least.
IMO in the case of package managers it actually makes it more readable. For example zypper (in openSUSE) uses a colored heading to group the packages it is going to install/upgrade/remove/etc and it uses a color for the first letter of each package, both making it very simple to quickly scan the packages that are going to be installed or affected whenever there is a big list of them - e.g. i can quickly skip all the libraries (since they begin with "l").
Obviously sometimes you might want to grep your logs and then color sequences might be annoying. I guess there is a command line tool / sed / awk oneliner to remove them. Unix filters are from the 1970s after all.
The question is just what is the tool. I'd guess SO knows... But it's Sunday morning and I am on my phone not motivated to work :)
The more sparingly you use colour, the more effective it is as a means to highlight important information. Different users think different information is important.
I'm not sure how widespread it is but I work in the mining industry and I've seen a trend on newer installations towards keeping the general appearance of the entire interface to a couple of modestly contrasting neutral greys. Only parts of the plant which require operator attention are shown in colour (I think plant that's not in the normal automatic operation mode was yellow and alarms were red). The information's still all there and easy to read if the operator wants to, but it's not screaming for your attention unless it actually needs it.
Compare this with the usual visual confetti of brightly flashing colours that a SCADA system devolves into, especially after a few years when a lot of 'important new features' have been added 'which the operator needs to see'.
Note btw that one might have a wildly different perspective as e.G. Developer using a few tools on their own controlled desktop a lot, vs e.G. a sysadmin constantly jumping between large number of tools on large number of systems. As such, having a simple variable to shut up all the apps on all the servers may be quite handy.
PuTTY comes to mind immediately upon reading this sentence. It is used more often than I like.
https://www.chiark.greenend.org.uk/~sgtatham/putty/
The default colorscheme is extremely bad and if you use Vim to open log files, the comments are unreadable because they're colored as dark blue on a black background. Most of the other colors are unreadable as well. The widespread usage of PuTTY in my organization is the reason I have never written scripts or programs with colors, even though colors would help a lot of people differentiate between benign, warning, and error messages.
Colorized output really sucks when the output is displayed in a terminal that doesn’t support it. Visual Studio’s build output, online build terminals like CircleCI, log viewers, …
(Unsure if the ones I list above actually do have an issue with colors, but absolutely sure that I have seen it many times.)
Would it be nice if every pipeline tool supported the gambit of colors? Maybe, maybe I wouldn't care then. But as it is, more often than not, your cute colors just garbage up my build output.
What you might be missing is that “color” on the CLI is actually extra characters before and after a colored word. If the viewer does not interpret them (for example a web UI), they will just be extra characters. This is akin to printing `<strong>8000 bytes</strong>` and expect it to be rendered correctly everywhere it’s shown.
2. Some color-using CLI tools assume white-ish background and actively use dark blue which is hard to see on a black background.
ls -la
Some terminals have picked their default ls colors so bad that some entries are almost unreadable. Dark blue on black etc. Forced me to configure the LS_COLORS.
Deleted Comment
But sometimes software that I use irregularly, or only in specific circumstances, does it poorly, and it's a real pita. I've had occasions where I missed entire pieces of output because they rendered as the background color for some reason. So for those cases it'd be nice to have a universal switch, so to speak, to just turn it off.
I also get that for some people it's just an aesthetic choice... I don't think color is _that_ helpful that someone would be impaired by not having it.
All that said, this proposal reminds me of that one xkcd with the 13 competing standards.
https://github.com/Cloudef/bemenu#environment-variables
In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts or overridden on the command line before executing a command, which is extremely annoying.
Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. It's no different than setting up an alias, and I'd rather use a wrapper script or alias than have to remember how the app is configured, or search my history for the correct invocation.
In fact, environment variables are a very flexible way of configuring an app. They're generic, work the same across apps (no worries about the various ways of specifying flags), avoid the need for a custom configuration file, you can have multiple .env files and load them with env(1), etc.
I'm a big fan of following the 12factor[1] approach.
[1]: https://12factor.net/config
It might also be that COLOR is already used for other purposes by some software.
But I guess that ship has sailed.
https://github.com/alrs/nofun
I'm sure you can even do some clever bash-foo to run your term sessions through it, like how screen or tmux work.
Why prefer
over ?The latter seems both cleaner to me and it doesn’t require modification of all existing CLI programs to work.
> One could do this with GNU sed, but developers working in proprietary operating systems don't have GNU sed.
"... should check for the presence of a NO_COLOR environment variable that, when present (regardless of its value), prevents the addition of ANSI color ..."
How common is this behavior ?
That is, the presence of the env var regardless of its value trips the conditional ?
That seems like asking for trouble / confusion ... especially since there is a very well understood practice of setting 0/1 false/true for settings like this.
Is this commonly done and I have just never noticed it ?
And
NO_COLOR=
would lead to an non-intuitive behavior
Pretty normal, yeah. You can `unset FOO` a variable to set it to false.
I would assume that COLOR implies that only color escapes should be disabled, but the description also mentions “plain” output.
The problem is when people use explicit escape codes in their code rather than using libraries that solved this problem all the way back in the 80's.
Yes, I'm somewhat grumpy about this because far too many times I have found log files filled with escape codes, or colours that are absolutely unreadable when using a terminal with white background.
If you support NO_COLOR you're making things worse.
There is ansi2txt (packaged as colorized-logs on debian).
https://github.com/kilobyte/colorized-logs
I also found some answers on SO with people using a sed command for this.
https://stackoverflow.com/questions/17998978/removing-colors...