> 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?<p>> 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.<p>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.<p>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 <i>some</i> color (prompts but not applications). Can someone with this opinion explain their rationale?<p>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'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.
For tools that don't honor NO_COLOR, I have a filter called nofun, which gets rid of color and animations.<p><a href="https://github.com/alrs/nofun" rel="nofollow">https://github.com/alrs/nofun</a>
I think this is a fine idea but I wonder about this part:<p>"... should check for the presence of a NO_COLOR environment variable that, when present (<i>regardless of its value</i>), prevents the addition of ANSI color ..."<p>How common is this behavior ?<p>That is, the presence of the env var <i>regardless of its value</i> trips the conditional ?<p>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.<p>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.<p>I would assume that COLOR implies that only color escapes should be disabled, but the description also mentions “plain” output.
Competing standard for CLICOLOR and CLICOLOR_FORCE variables that have some support: <a href="https://bixense.com/clicolors/" rel="nofollow">https://bixense.com/clicolors/</a>
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.
Definitely adding this to my todo list to add to the CLI tools I help maintain. A lot of modern tools add emojis to output as well, which I sometimes find unnecessary in a similar way to terminal colours.<p>NO_COLOR and NO_EMOJI seem reasonable. Any other ideas?
I agree that an env variable would be "philosophically" the right thing to do ("no colors" is a user choice and programs should respect user choices).<p>However, giving a standard enough momentum so that most developers will actually implement it is an incredibly hard thing to do. I honestly don't have much hope that this will reach enough projects to be practically usable. At least not without support/enforcement by distributions.<p>I also think that modifying shells instead could be a more pragmatic and effective solution - simply because there are less people you'd need to convince.<p>You could get the same outcome however by having the <i>shell</i> interpret the NO_COLOR variable and have it strip colors from each subprocess where it is set.<p>Also, I believe, most programs automatically disable colors when they detect that STDOUT does not point to a terminal. So couldn't you have the same effect by simply appending "| cat" to your command?
I wrote a shell script some time back that stripped ansi color from piped output. Haven't needed it since, but can't be hard to make again. So probably we don't need this kind of quasi-standard.<p>(what's up with all the non-IETF "standards" all over HN and GitHub? there is an open standards process for technology, people. is the problem that us old folks never taught the youngsters how to make them?)
> While some developers and users obviously prefer seeing these colors, many users don’t.<p>This is bold. (Pun intended).<p>Colors are immensely beneficial for opt-in. I haven't heard very many complaints about it -- why does the author assume many users don't?
I think it's reasonable to want an easy way to disable colored output, but I don't get why TERM doesn't work. Unless the request here is not for no colors but instead for fewer colors.<p>But if it's to disable all colors in applications, then I believe changing TERM should work. And if you run something that you want colored you can override TERM for that process.
The difference between Colour and non-Colour is more precisely expressed as the difference between chromacity and lightness. We must not forget that chromatic vision developed after lightness vision. The former developed as response to the availability of fruit. Effectively, fruit and chromatic vision co-evolved.<p>At a more experiential level, chromatic vision is an elaboration. It is not required, but in the lives of our ancestors, its presence signified the availability of a rare and pleasurable (carbohydrate intensive) experience.<p>In design, this principle carries through. Colour is a layer that lays on top of the lightness experience.
Conversely if you want to add color to a command, I have found Generic Colorizer to be useful: <a href="https://github.com/garabik/grc" rel="nofollow">https://github.com/garabik/grc</a>
This is the type of thing that should be supported in higher-level libraries like Chalk[0] (maybe it is?). We all know that Joe Bloggs' CLI isn't going to be checking for NO_COLOR.<p>[0]: <a href="https://www.npmjs.com/package/chalk" rel="nofollow">https://www.npmjs.com/package/chalk</a>
If something doesn’t have an option to disable color, I simply pipe its output through `cat`.<p>This is also handy for `git` commands that insist on showing a pager for fewer than a full screen worth of lines of output.
I started to avoid tools dumping excessive color output, especially with emoji. This is ridiculous and extremely untasteful. Good tool must produce zero output.
I usually handle this inside code. Colour output operators make loss difficult to read. An associated commit and message is a sign to developers that the software runs in environments without colour consoles. Finding a way to shoehorn an environment variable into a build pipeline feels like an antipattern.
What drives me <i>insane</i> is the UEFI shell using dark blue text for some things. That's impossible to read with a black background. The last place I want to squint and guess at what something says is when I'm applying a firmware update via a uefi tool, or un-foobaring a bootloader..
Submitted a few times in recent year. <a href="https://news.ycombinator.com/item?id=21171274" rel="nofollow">https://news.ycombinator.com/item?id=21171274</a> is the only one I can see, after a very cursory search, that got any discussion going at all.
Great idea!<p>For those wondering why anyone might not like their oh so beautiful colours...<p>I like to set the background colour of the terminal to light green, and the text to black. It's much more relaxing. Coloured output is often illegible with this setup. Plus the colours are silly anyway...
Unrelated but is there a standard that keeps my ~/ home directory clean? I don't want billion apps to write ~/.foo_software_config to my home dir. It is a complete mess.
I just use a bash alias for striping colors:<p><pre><code> alias stripcolors=' sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g"'</code></pre>
How generally are people dealing with these coloured logs when ingesting them into a centralized logging system? Is there much overhead in stripping these sort of things out.
>I want to use weird terminal themes that don't visually work well with most programs<p>>therefore every single program must modify itself to accommodate me<p>Uhhh, nope?
This article reminds me a bit too much of <a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a><p>Unless every program individually decides to implement NO_COLOR, this just adds yet another way that a program MIGHT allow you to disable color. Even if 90% of them implement it, it could just lead to issues whenever you unexpectedly run into a program in the remaining 10%.
in the last 20~ years, i see more and more programmers not being able to read (source) code if it is not colored somehow. Or to navigate without a mouse.<p>it's like you are on a journey, and your vehicle breaks in middle, and you do not continue by feet.. because you don't know you can walk.
> many users don’t.<p>I doubt the "many" parts.<p>It sooo much more readable if your program outputs a lot of data.<p>And any (proper) implementation automatically switches the escape codes of if piping to another program instead of terminal so it rarely causes problems.<p>I'm sure there are still some people which do not like it, and there are some libraries which mess up colors without doubt.<p>So I'm fully in support of NO_COLOR as a "de-facto" standard.