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

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.

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.

I am not speaking without experience. If you support Windows, you probably need to support non-console environments like cygwin and msys. Moreover, Windows 10 has opt-in support for ANSI style coloring. At some point, coloring via the console APIs will probably stop being used.

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.