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

[burntsushi]

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.