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 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.
Edit: missing not
This feels like complaining that Spotify doesn't have a silent mode for people who dislike sound. /shrug
And the color themes for the terminal are godawful. No matter how you spin 16 colors, how solarized or other, everyone is kind of chained more or less to that attrocious 16 color pallet, which is always going to be way way higher contrast or low-fi than something like a vim theme that can pick some complementary colors to work with.
Colors feel like my terminal punching me in the face. No thanks.
Also have you ever logged into ubuntu? Holy shit colors were a TERRIBLE idea.
HN discussion: https://news.ycombinator.com/item?id=3717303
What I think would be good (for me at least) is not colors, but sort of markup, like bold or underline, which is available in terminal as seen in man pages and PS1. I usually make them bold and compatible colored.
Another bonus is that I don't feel cheated when I log into systems that don't support colors (*BSD, Solaris, etc). Everything just looks normal to me. Even non-syntax highlighted vi (not vim).
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" }
^ I have not run the above program, only proven it to be correct.
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/
I suppose in that sense it does aim to be fast. Fast for the human to parse.
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.
I know ripgrep has a ton of fantastic optimizations by Burntsushi.
You might wanna check it out...before making such statements.
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?
My actual (light) advice is merely that we're all guilty of inappropriately using IO redirection facilities that punish the performance of our shells. `cat <filename> | grep <expression>` should be replaced by `grep <expression> <filename>`.
No doubt that pipelines are easier to read. The author has a whole section in README demonstrating blush's ability to read STDIN - nothing is lost by using best practices everywhere else. Documentation matters, and it should communicate best practices.
< FILENAME blush "some text"
I'll give it a try. I normally use a different Golang tool called sift as my grep replacement (which I love so far): https://github.com/svent/sift
Sift's goals seem to be mostly performance (it is super fast), but it would be nice to have some of these more sophisticated coloring features in there as well, as they are useful.
