Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Grep with colours written in Go

github.com

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Show HN: Grep with colours written in Go

#81

Post by masukomi »

abstractbeliefs wrote: post #5

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

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

Re: Show HN: Grep with colours written in Go

#82

Post by masukomi »

wruza wrote: post #23
vanattab wrote: post #19

Earlier quoted context omitted.

My guess is the ansi color escape codes mess with peoples parsing code of the output when scripting.

All sane tools check if output isatty(3) before doing that.

as @abstractbeliefs said, there are a lot that don't, but personally i hate it when apps do that because it removes my ability to actually maintain the colors through pipe chains. It's much harder to convince an app to maintain color through a pipe from an app that does this than it is to remove color from an app that doesn't pay attention to tty or not.

Re: Show HN: Grep with colours written in Go

#83

Post by laumars »

samatman wrote: post #79
laumars wrote: post #53

Earlier quoted context omitted.

Sadly that only removes 1 of the 3 methods of escaping terminal colours. Plus there is also the risk of it removing other SGR (Select Graphic Rendition) escape codes such as underline. That latter bug might be an acceptable casualty though.

It was meant to remove underline, bold, dim, and even blink. Are there xterm codes for generating terminal color that don't end in m? It handily covers 8/88/256/24bit. What else is needed?

24bit uses the colon character as well. So if you're wanting to remove all SGR escape codes* then it's a pretty minor additional to your regex.

* Personally I quite like the bold and reset SGRs even when I don't want the term colourised. Bold can highlight text without drawing your attention away from the main body of the terminal.

Re: Show HN: Grep with colours written in Go

#84

Post by laumars »

mlevental wrote: post #75
laumars wrote: post #34

Earlier quoted context omitted.

In fairness, it's the GPs fault on this occasion for not punctuating his or her post. Decarep just read the GPs post as it was literally written (I had to read it 3 times myself to gauge what I thought the post meant).

contextualization is a component of reading comprehension

The post still made contextual sense when read literally. It just wasn't technically accurate. Hence why it was so easy to misinterpret.

Plus the next time you make sweeping generalisations about the reading comprehension abilities of HN it is probably worth remembering that this is an international community and thus English isn't going to be everyone's first language.

Re: Show HN: Grep with colours written in Go

#85

Post by samatman »

laumars wrote: post #83
samatman wrote: post #79

Earlier quoted context omitted.

It was meant to remove underline, bold, dim, and even blink. Are there xterm codes for generating terminal color that don't end in m? It handily covers 8/88/256/24bit. What else is needed?

24bit uses the colon character as well. So if you're wanting to remove all SGR escape codes * then it's a pretty minor additional to your regex. * Personally I quite like the bold and reset SGRs even when I don't want the term colourised. Bold can highlight text without drawing your attention away from the main body of the terminal.

I'm still looking for the use of ":" in xterm codes, but already discovered that this is a thing:

"\033]11;#53186f\007"

So, bare minimum, I'll need to include # in future. you can /generate/ 24 bit color using only ; and digits...

When filtering ANSI I'm usually streaming the result to something that expects pure ASCII, and tuning sed to only accept two escape codes would be a pain in the neck.

Re: Show HN: Grep with colours written in Go

#86

Post by sliken »

JackCh wrote: post #4

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

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.

Re: Show HN: Grep with colours written in Go

#87

Post by laumars »

samatman wrote: post #85
laumars wrote: post #83

Earlier quoted context omitted.

24bit uses the colon character as well. So if you're wanting to remove all SGR escape codes * then it's a pretty minor additional to your regex. * Personally I quite like the bold and reset SGRs even when I don't want the term colourised. Bold can highlight text without drawing your attention away from the main body of the terminal.

I'm still looking for the use of ":" in xterm codes, but already discovered that this is a thing: "\033]11;#53186f\007" So, bare minimum, I'll need to include # in future. you can /generate/ 24 bit color using only ; and digits... When filtering ANSI I'm usually streaming the result to something that expects pure ASCII, and tuning sed to only accept two escape codes would be a pain in the neck.

ISO 8613-6 uses colons. Admittedly it's a less supported standard.

Sadly handling terminal escape codes is one of those impossibly painful jobs. Heck, often even the terminals don't seem to support the escape codes they have documented or the documentation is so poor that you're basically left with trial and error (or a shit load of hex dumps to trawl through if you're lucky). eg I've wasted hours trying to get Kitty specific escape codes working on that terminal emulator before giving up.

I'm investing a lot of effort at the moment learning escape codes because I'm writing a new $SHELL which is designed to have rich media support even in $TERM's which don't support rich content. But I do still have support to convert the $SHELL back into a black and white console (I even have an option to strip colour from the STDOUT (even when pipelined) of all processes negating the need for your sed command. However that feature hasn't yet been committed back to the master branch.

Re: Show HN: Grep with colours written in Go

#88

Post by megous »

mbrumlow wrote: post #69
megous wrote: post #62

Earlier quoted context omitted.

> Another workaround is to merely pipe the output to a file in certain cases. If that works for a certain tool, it's author really has no excuse to not implement NO_COLOR env as well.

Piping the output does not guarantee the removal of the color codes. This is yet another standard some programs have chosen to implement. The program checks if the output is a tty, if it is not a tty it will drop color information as it is either a pipe or a file. The escape codes would look ugly in a file and could get in your way with some text processing programs. Even if the program did drop color when not sendin…

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.

Re: Show HN: Grep with colours written in Go

#90

Post by arsham »

sliken wrote: post #86
JackCh wrote: post #4

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

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.

Thank you for doing the comparison. Would you do the same against the latest version (v0.5.0) please? Thank you.
Post reply on HN