[ggreer]

I don't understand why this is a standard.

First: It requires that every command line tool add support for this environment variable. It may not be much effort for each project, but it adds up to a ton of developer time. Even if this standard gains traction, some apps will slip through the cracks. So in the success case, many users will still be annoyed that one or two of their tools print colors when they shouldn't.

Second: As the FAQ on that page mentions, people can configure their terminal emulators to squelch color. NO_COLOR only matters for users who want color in some applications and not others. In that case, are certain applications supposed to refuse supporting NO_COLOR? Will all users want the same set of programs to behave that way? Are users supposed to unset NO_COLOR before running those programs?

At that point, it seems like a more complex version of using some aliases that add --color=never (or whatever the appropriate flag is). Or if the user prefers to disable color by default, they could set $TERM to "xterm-old" and alias their favorite commands to add --color=always. Either way, there's no need for another environment variable.

Really though, this seems like it should be a feature of the shell or the terminal emulator. Does the process name match certain patterns? Pass color codes through. No? Strip them. That would solve the problem for all programs past, present, and future. And total development effort would likely be less than that needed to implement NO_COLORS in every command line tool.

[abstractbeliefs]

I'll speak for my case specifically: a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value.

I think it's apparent that this isn't something you're really keen to support in ag in the few times I've seen you talk about it, so feel free to close the PR I have open there rather than leave it hanging without any reply.

https://github.com/ggreer/the_silver_searcher/pull/1207

[the_af]

> a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value.

Your use case seems perfectly valid to me, but how would NO_COLOR help you? Wouldn't it suppress all color in all programs when it's set? Assuming everyone gets on board, of course.

[mbrumlow]

Yeah that seems to be what he wants!

He can then selectively enable color on the programs he wants by simply unsettling the NO_COLOR variable before execution of the program.

[wruza]

What if someone needs colors, but not colors that util maker used? What if two or more tools make different use of colors? With terminal aware of that problem you can remap or erase specific colors, but maybe it’s wiser to not create a problem at all, since just making text bold may be enough for practical needs.

Edit: missing not

[giancarlostoro]

Sounds like a better standard is being able to define color schemas for CLI utilities. Would be pretty awesome if this were possible, though many utilities vary in what type of output is colored a certain way sadly.

Another workaround is to merely pipe the output to a file in certain cases.

[megous]

> Another workaround is to merely pipe the output to a file in certain cases.

If that works for a certain tool, it's author really has no excuse to not implement NO_COLOR env as well.

[mbrumlow]

Piping the output does not guarantee the removal of the color codes. This is yet another standard some programs have chosen to implement.

The program checks if the output is a tty, if it is not a tty it will drop color information as it is either a pipe or a file. The escape codes would look ugly in a file and could get in your way with some text processing programs.

Even if the program did drop color when not sending output to a tty it still is a crappy way to remove color as the pipe would need another program as a receiver such as pager.

[burntsushi]

> Even if the program did drop color when not sending output to a tty it still is a crappy way to remove color as the pipe would need another program as a receiver such as pager.

You don't need a pager. cat works. Compare

    grep --color=auto hacker /usr/share/dict/words

with

    grep --color=auto hacker /usr/share/dict/words | cat

The same applies to GNU ls, which actually changes more than just colors depending on whether it's printing to a tty or not.

Programs that emit colors by default when not sending output to a tty are buggy.

A wild card in this mix is Windows. On UNIX-like systems, detecting a tty is simple. On Windows, it is... not so simple. But the OP's tool, blush, doesn't appear to support Windows at all anyway. (Which is totally cool. I very much understand why you might not.)

[mbrumlow]

Yeah, I did not mean to imply you needed a pager, just something to receive the output, a pager is just one choice.

I guess the program implemented the tty method you could always alias your stuff to something like blush="/bin/blush | cat" if you decided you did not like color.

While a part of me says piping programs to get the result you want is the *nix way. Another part of me feels like it would just be a dirty hack to avoid color.

[tom_]

I don't think it matters so much on Windows, because the colour information is sent out of band. When you call SetConsoleTextAttribute on the STD_OUTPUT_HANDLE, and that handle is a file, the call simply fails.

[megous]

That's the point. If the program is already doing isatty() and thus has code for color/no-color output already, just adding getenv("NO_COLOR") is a no-brainer.