Show HN: Grep with colours written in Go

[abstractbeliefs]

Do be sure to at least consider supporting no colour! http://no-color.org

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

[notheguyouthink]

I'm confused, with a tagline like "grep with colors!", wouldn't you just use grep if you don't want colors?

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

[teamhappy]

Why wouldn't you just write a command line tool that strips the color escapes and then set up aliases like alias ag='ag | nocolor' or whatever. Seems much easier than trying to convince every developer out there to support your environment variable.

[barrowclift]

Genuinely curious, why do some developers prefer not having colors for ls, grep, etc.? no-color.org mentions that many users prefer having colors disabled, but didn't list any reasons why.

[gitgud]

What a great idea for a standard, so the tool will check the NO_COLOR environment variable, to see if it should display color.

[notinventedhear]

+1 for NO_COLOR.

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" }

[samatman]

| sed -e /\x1b\[[0-9;]+m//

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

[arsham]

There is a --no-colour/--no-color argument you can pass.

[masukomi]

this seems a far worse solution than pushing for a standard of encouraging apps to support --no-color

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

[JackCh]

Is this speed competitive with tools like the silver searcher (`ag`) or is the focus here on color?

[lillesvin]

As much as I love `ag`, I feel like ripgrep (https://github.com/BurntSushi/ripgrep) deserves mentioning when it comes to speed. If you haven't tried it, do it sooner rather than later.

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

[mvkg]

A quick look at the source shows that it appears to be linear and just uses `strings.Contains` or `r.MatchString` on each line, so I don't think it has any of the optimizations that are built into `ag`.

[nazri1]

I'm okay with it being not as fast because speed is not the goal here, but rather highlighting specific patterns to make it easier to spot for the human eyes, especially when tailing log lines from your development webserver.

[sliken]

I've got the linux-4.17 kernel tree around, 61,322 files.

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.

[valarauca1]

I’m doubtful ag and rg use a lot of smart optimizations to get their speed.

[ereyes01]

Nice job! Language-specific coloring is really nice!

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.

[arsham]

Cheers mate!

[tex0]

Nice UI! Some time ago I wrote something similar, because I was missing some features in ripgrep (which is otherwise pretty awesome): https://github.com/dominikschulz/gg

[xab9]

I like it. I started something similar with node (I never aimed for performance) trying to go for high grep compatibility but with added extra colors and js regexp flavour.

[megous]

GNU grep has support for colors.

[kbd]

Please reread the examples, which are specifying multiple searches and custom colors for each type of match, something that GNU grep can't do.

[teekert]

But... Can it elegantly suppress broken pipe errors?

[arsham]

Handling signals are not implemented yet. I appreciate it if you file an issue when you find any. Thanks.

[grblovrflowerrr]

Really cool! But from the title I initially thought this was a grep tool for finding certain colors in your image data.

[madmax96]

Useless use of cat candidate.

[dagenix]

This is one of my pet peeves - complaining about technically unnecessary, but fully benign uses of cat.

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?

[axaxs]

There's a difference between useless and unnecessary, both in definition and how a reader views the statement.

[s17n]

It's clearly there to demonstrate the pipe support...