Instead of trying to get every CLI tool in existence follow this standard, it makes much more sense to put this support in the terminal emulator or shell. Both can know what process is in the foreground and can strip color or let color through based on a user-configured whitelist/blacklist.
I think the main reason for disabling color output is the programmatic use of the output. It is easy to remove color within pipes (c.f. https://stackoverflow.com/questions/17998978/removing-colors...), however quite cumbersome to clean the output of each potential program just to make sure nothing breaks.
I guess the terminal should not start putting hands into this game since stdout is generally assumed to be binary (not even text).
That's already a solved problem though, with a different solution - programs should be checking `isatty()` and not output escape sequences if it's not going to a real tty. That's how `ls` can display colors by default but still not have them show up if you pipe `ls` into a command.
This page seems to purely be about interactive use with no color.
That's why you pair it with a command line switch:
--color=auto (default, isatty + termcap)
--color=always
--color=never
Now if we could only agree on a standard to do this using environment variables... Unfortunately, the most widely known "standard" [0], is still very rarely supported.
That's a pretty niche case, you can force it by either allocating a pseudo tty or using LD_PRELOAD with an isatty() shim that returns true.
I only ever had to do it once (using LD_PRELOAD) because there was an insane vendor binary blob that would return "SUCCESS" in green/red depending on if it passed or failed. When isatty() returned false, it was impossible to tell if it passed or failed, but the software was pure garbage.
I don't entirely agree. When I do want colour (generally because I've taken the time to configure the program suitably for it), then I usually still want the colour when I pipe its output through a pager. `diff` is the canonical example.
Edit: Another comment¹ points out pipetty² as a workaround, so I learned something useful today.
> I think the main reason for disabling color output is the programmatic use of the output. It is easy to remove color within pipes (c.f. https://stackoverflow.com/questions/17998978/removing-colors...), however quite cumbersome to clean the output of each potential program just to make sure nothing breaks.
Most programs that output color already disable color if the output isn't a terminal; in fact I just pipe the output to cat when I want color off.
Shouldn't you rather use $TERM=dumb (or unknown) for this, since there are plenty of other escape sequences that you also wouldn't want?
The author has a use case (I believe their issue is that unlike $NO_COLOR, setting $TERM takes precedence over any configs or --color flags), though to me it seems like a rather niche problem. Anyways, if you support $TERM, it's easy to support $NO_COLOR as well, so there's not much of a reason to not follow the standard.
> Shouldn't you rather use $TERM=dumb (or unknown) for this, since there are plenty of other escape sequences that you also wouldn't want?
Lots of software out there, especially from nodebros, blithely ignores $TERM and just barfs ANSI escape codes to standard out, under the rubric that, well, everybody uses macOS Terminal/iTerm/Alacritty.
True. But this is a problem that should be addressed with equal to if not far more fervour than pushing some other environment variable.
Because although the meanings aren't specified the TERM environment variable itself is named in the Single Unix Specification, unlike some other environment variables (even COLORTERM).
And the TERM=dumb convention is documented widely and long, at least as far back as 1983, in books and in on-line doco.
* It's in the McGraw-Hill book _Introducing the UNIX System_published in 1983. Amusingly, this uses the C shell setenv syntax to demonstrate setting it, indicating how the C shell was the Bourne Again shell of its time.
* It is the documented default fallback for AT&T Unix System 5 Release 4's tset(1) command when nothing in the the ttytype(5) file matches. "If the serial port is not found in /etc/ttytype, the terminal type is set to dumb." said the USL manual.
(No, it's not the ncurses tset(1)'s fallback. Bear in mind that the "n" in "ncurses" meant "new". ncurses was a reimplementation. Like many reimplementations, it missed bits of actual System 5 Release 4.)
* Setting TERM to the right thing instead of a dumb terminal type in order to enable colour is in Coffin's _UNIX System V Release 4 Complete Reference_ published in 1991.
This is how long and wide a pedigree TERM=dumb has.
Not true. Indeed, very much the other way around. All software that uses the terminfo or termcap databases looks at the TERM variable and gets the TERM=dumb effect from that for free. That's every shell script that uses tput to change colours, and every program that calls the low level tgetent()/tigetstr() (or the equivalents in unibilium or termdb) or that uses curses/ncurses.
This is a wide range of softwares from the %F and %B sequences in the Z shell's prompt through Midnight Commander to the clang++ compiler.
You've clearly either never looked at much doco or have a truly terrible memory. In addition to all of the books and whatnot over a span of 40 years, even The Linux Documentation Project got in on the act: https://tldp.org/HOWTO/Text-Terminal-HOWTO-8.html#early_term...
Most of the software that outputs colors are scripts or CLI programs that use hard-coded ANSI escape sequences, not termcap or those library functions.
You haven't measured it, and the large number of questions and answers on just Unix StackExchange, without checking all of the others from AskUbuntu to SuperUser that are like https://unix.stackexchange.com/a/327544/5132 indicates that yes, people do use tput in scripts as a matter of course.
I don't know all the intricate details of how these things work, but my general impression is that the terminal should really not be able to see or modify data being sent over pipes. The shell can, but you wouldn't want it unconditionally scraping and "cleaning" what is usually an opaque binary stream (even if it contains mostly text). So you can make it an option, but wouldn't it be better if programs just provided a standard way to turn off color coding?
I personally don’t like having to ask a friend to adjust a bunch of terminal settings (or worse, use a specifically accessible terminal like you are suggesting) just so I can look over their shoulder without my eyes bleeding.
I also don’t think anyone is asking you to go change all the software in the world to support NO_COLOR=1 just to help people out.
I do think it would be great if the next time you thought about putting a little colour in your application that you consider supporting $NO_COLOR to disable it. It would help me and others out if I ever found myself using your software.
I do agree that the terminal you suggest (if it existed and were common) _would_ be better than NO_COLOR=1 but I hope you can also understand we don’t live in that world, and that the “best” solution in one way, isn’t always the best way to help people out.
Finally, I hope very much that you can think about accessibility in the future: asking the disabled to work harder is not a kindness- it may be unrealistic to do anything else, but you can try to make it as easy as you can, and that is a kindness.
Colors are usually stripped when the output is piped, so simply piping a command through cat should already do this most of the time.
Using a global standard for color configuration would be nice, though. I often want coloured output and am left with all kinds of command line flags or environment variables just to get tools to output text normally.
> 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.
> It is reasonable to configure certain software such as a text editor to use color or other ANSI attributes sparingly (such as the reverse attribute for a status bar) while still desiring that other software not add color unless configured to. It should be up to the user whether color is used, not the software author.
I have no problem contributing patches, but nothing I currently use regularly is ill-behaved.
Not using colour is no work at all. Using colour correctly is a fair bit of work, and few programs do so; practically none check whether the terminal background is dark or light before emitting a dark blue or light yellow.
Aside from your uncharitable interpretation: it is really not difficult or time-consuming to support this. It's just setting and checking a single boolean flag, in fact it may simply just be a few lines at startup if the tool already supports color options via cli args.
Indeed, if one uses the termcap or terminfo libraries (or the likes of unibilium) to obtain the control sequences for colour from those databases, instead of hardwiring them into the source code of print statements, one gets the TERM=dumb convention implemented entirely for free.
In this case it seems pretty easy to contribute a patch? Mature projects have unit and screendiff test suites that need to be updated and extended to verify the new case, so it might not be THAT easy even for a trivial change.
I read the page before commenting and it didn't address my point. That answer is about why it's not satisfactory to simply disable all color in the terminal. I'm talking about adding a color whitelist/blacklist feature to a terminal emulator.
No, it really doesn't. There are so many tools that already respect this variable that if you're writing a new tool, and you're not looking for that variable, you are being a bad actor and need to be told to shape up.
