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.

That’s still up to the developer of the producer to implement

Piping to cat won't work for an interactive tool though.

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).

Shouldn't you rather use $TERM=unknown for this, since there are plenty of other escape sequences that you also wouldn't want?

I would imagine there are use cases for $NO_COLOR, though to me it seems like this is 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 if not far more fervour to 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's in the 4BSD manual page for TERM(7) from 1985. It's still in the OpenBSD manual page for term(7) to this day: https://man.openbsd.org/term.7 . The 4BSD TERM(7) manual had a list of well-known types, and "dumb \ \ \ \ \ \ \ \ terminals with no special features" was one of them. See https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/man/... for example.

* 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.

Even I, who is progressive enough that I have joined the bright new future of 1976, with my softwares defaulting to TERM=ansi if it isn't set, document the convention that TERM=dumb meant using no escape or control sequences and just (a few) C0 control codes such as LF and CR. See https://jdebp.uk/Softwares/nosh/guide/commands/TERM.xml and https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47... . And yes, I implement that convention. "dumb" gets several mentions at https://jdebp.uk/Softwares/nosh/guide/commands/TerminalCapab... .

It may be old but it isn't popular. I've spent 10k+ hours in the terminal and don't remember ever seeing it mentioned.

Almost all software that outputs colors only checks if the output is a TTY and doesn't look at the TERM variable.

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...

And StackOverflow: https://stackoverflow.com/a/39005551/340790

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 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.

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.

The isatty() check is obnoxious when you do want to preserve the control chars and can't force it on.

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.

> That's a pretty niche case

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.

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.

[0] https://bixense.com/clicolors/

Yeah. If you don't like colors just diable them from the terminal.

They address this FAQ on the linked page:

> 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 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.

You don't know which process it is. The color producing program can be embedded in a script or running in an ssh session.

Is there some reason why we can’t just implement this once in each terminal?

Go into the settings, set “no colour” and it just strips all the escape codes from the stream?

Or just outright ignore them?

I guess it feels weird to want to make this the problem of every CLI application developer.

You could copy an existing terminfo entry and remove the colour.

Or use an existing one like ansi-mono

I want colour, in certain places, under my control. I don't want every random tool spewing confetti.

So you want every developer to spend time on both color and non-color options but are not willing to contribute a patch for that?

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.

> Mature projects have unit and screendiff test suites

Good joke.

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.

terminal emulators dont actually know this. Just think of executing something via ssh. In this case the primary foreground process is ssh.

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.

Agree, but even for terminal emulators imo it's better to put that as an option in the config menu / file instead of an ENV variable

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.