Show HN: Grep with colours written in Go

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.

^ I have not run the above program, only proven it to be correct.

For example, yellow text on a dull yellow background? No thanks.

For years I've just wrapped commands on bash to strip the colour control-codes from stdout.

function monochrome() { "$@" | sed -r "s/[[:cntrl:]]\[[0-9]{1,3}m//g" }

This feels like complaining that Spotify doesn't have a silent mode for people who dislike sound. /shrug

I think there are FAR fewer people who want it off everywhere by default than people who want it off occasionally

having all the arguments to your app be handling via dash args EXCEPT the one for color is non-standard, harder to explain in the docs, introduces an inconsistency to how your app is controlled, etc., etc...

Here's an excellent write-up on how it works, benchmarks, etc.: https://blog.burntsushi.net/ripgrep/

My desktop is running ubuntu-18.04, is an i5-3570, and has a fairly quick intel SSD.

Running "blush -R -i FunctionName ." takes 15.090 seconds and finds two files.

Running "ag -i FunctionName", finds one file, missing one in .clang-format.

Running "ag -i -u FunctionName", finds two files and makes 0.64 seconds.

So somewhere around 20-25x faster.

Yes, 'cat FILENAME | blush "some text"' and 'blush "some text" < FILENAME' do the same thing. But, what if you don't have permission to read the file - the former be re-written as 'sudo cat FILENAME | blush "some text"' - the latter form can't. What if you want to build a pipeline? I think its pretty persuasive that 'cat FILENAME | blush "some text" | sort' reads better than 'blush "some text" < FILENAME | sort' - the former reads from left-to-right, the latter reads from the middle, to the left, and then bounces over to the right. Tastes may very - but, I think its a hard sell that such an opinion is clearly wrong.

So, yes, its unnecessary. And, yes, in a script using cat like that can complicate error handling. But, for interactive use, what advice exactly are you trying to convey?