Though most of the software do the right thing by checking if the standard output is an actual tty (isatty) to avoid colors when redirecting to something else (e.g. socket, fifo, etc).
The name NO_COLOR suggests a really binary choice which may be okay. Though GNU coreutils usually have a more selective option like --color=always|auto|never.
I'd prefer supporting a more general COLORS=on|off|compatible|...
Meaning:
- on: always on even when redirecting
- off: fully off
- compatible: maybe something like on by default and off if redirecting to a non-tty
- ...: add more choices
cb321 15 hours ago [-]
> do the right thing by checking if the standard output is an actual tty (isatty)
This is a very questionable heuristic. I'm not sure the exact date that support began, but I have been piping color output to `less -r/-R` for decades. This can be nice even for less than multi-terminal-page output just for "search".
isatty(stderr) would actually be more accurate for my specific use cases for when I don't `|&` or maybe even `isatty(stdin)`, but those are also imperfect heuristics.
The point is, since "auto" is a questionable heuristic, it is not so crazy/wrong to just default to color-on and have an off switch and that off switch is what NO_COLOR is about (as explained by the very first sentence in the linked article). Desirable defaults ultimately depend upon the distribution of your user's tastes (as always, more|less).
sudahtigabulan 16 hours ago [-]
> Though most of the software do the right thing by checking if the standard output is an actual tty (isatty) to avoid colors when redirecting to something else (e.g. socket, fifo, etc).
NO_COLOR is orthogonal to the isatty suppression.
NO_COLOR ensures that colors are off even when stdout is not redirected.
For example, when you have poor vision, poor quality display, or sit near a window, (or worse – a combination of these) the colored parts of the output might have lower contrast, low enough to make them impossible to read.
yjftsjthsd-h 14 hours ago [-]
Yeah, my first thought on seeing this was that I really want a way to force color just as easily; when I output diffs in CI, they're much more readable with color but it's a pain to enable it when running headless.
bhaak 13 hours ago [-]
I'd argue that if somebody implements NO_COLOR support they will likely also implement a --color switch to force color.
At least I do. :)
blueflow 18 hours ago [-]
Neither "curses" nor "ncurses" are mentioned on the page - that would be the traditional place to implement such behavior. terminfo still has xterm and xterm-color separately, so this functionality used to exist ($TERM based, tho) before go and rust.
trashb 16 hours ago [-]
Isn't there already a lot of separate implementations around color handling?
It would be good to unify it, perhaps some of the distributions can also have a hand in it.
terminfo also has "Mono mode" with the "-m" suffix which I don't see mentioned in the article.
Does NO_COLOR=1 mean that all ANSI formatting should be disabled? Including bold text, italic text, and so on?
It seems that different software handles that question in different ways.
willm 14 hours ago [-]
I asked the author a while back. They said it purely relates to colour. Not other styles. Alas, they removed the issues and there is no record of that.
antonyh 17 hours ago [-]
Maven has the `-B` option, but that has the side effect of working in a no-input mode so it's not ideal. There's plenty of times I'd like to have it working interactively but without the ANSI colour codes.
aiiizzz 12 hours ago [-]
The terminal _really_ sucks for UI. I wish it was better
esseph 3 hours ago [-]
I couldn't disagree more.
18 hours ago [-]
post_on_hn 15 hours ago [-]
No, we need OS-wide setting to also change light mode and dark mode across GUI/TUI/console without restarting applications.
singularity2001 13 hours ago [-]
export NO_COLOR=1
had no effect yet
Rendered at 02:49:44 GMT+0000 (Coordinated Universal Time) with Vercel.
Though most of the software do the right thing by checking if the standard output is an actual tty (isatty) to avoid colors when redirecting to something else (e.g. socket, fifo, etc).
The name NO_COLOR suggests a really binary choice which may be okay. Though GNU coreutils usually have a more selective option like --color=always|auto|never.
I'd prefer supporting a more general COLORS=on|off|compatible|...
Meaning:
- on: always on even when redirecting
- off: fully off
- compatible: maybe something like on by default and off if redirecting to a non-tty
- ...: add more choices
This is a very questionable heuristic. I'm not sure the exact date that support began, but I have been piping color output to `less -r/-R` for decades. This can be nice even for less than multi-terminal-page output just for "search".
isatty(stderr) would actually be more accurate for my specific use cases for when I don't `|&` or maybe even `isatty(stdin)`, but those are also imperfect heuristics.
The point is, since "auto" is a questionable heuristic, it is not so crazy/wrong to just default to color-on and have an off switch and that off switch is what NO_COLOR is about (as explained by the very first sentence in the linked article). Desirable defaults ultimately depend upon the distribution of your user's tastes (as always, more|less).
NO_COLOR is orthogonal to the isatty suppression.
NO_COLOR ensures that colors are off even when stdout is not redirected.
For example, when you have poor vision, poor quality display, or sit near a window, (or worse – a combination of these) the colored parts of the output might have lower contrast, low enough to make them impossible to read.
At least I do. :)
It would be good to unify it, perhaps some of the distributions can also have a hand in it.
terminfo also has "Mono mode" with the "-m" suffix which I don't see mentioned in the article.
I see a lot of handing of color options in the standard Ubuntu .bashrc https://gist.github.com/marioBonales/1637696
It seems that different software handles that question in different ways.
had no effect yet