9 ms·
Show HN: Grep with colours written in Go
- deleted 8y ago[deleted]
- ereyes01 8y agoNice 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 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 8y agoCheers mate!
- JackCh 8y agoIs this speed competitive with tools like the silver searcher (`ag`) or is the focus here on color?
- mvkg 8y agoA 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`.
- arsham 8y agoThat is correct. The project is at its early stages. I want to see what the community need the most and shape the project towards that goal. On the other hand I tried to avoid optimisations until most of functionalities are implemented.
- ozkatz 8y agoIt's a very nice idea and you should be proud of what you've built, but my personal opinion is that speed is a core feature of `grep`. A good place to start would be this: why GNU grep is fast[1] - Starting with the Boyer-Moore string search algorithm and reading through the optimizations done in GNU grep. p.s. there's an implementation of Boyer-Moore hiding in Go's standard library. [1] https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...
- arsham 8y agoThanks mate, I will definitely have a read.
- burntsushi 8y agoNote that you don't need Boyer Moore for the common case. ripgrep for example will very rarely use Boyer Moore. Its work horse is much simpler and typically faster: https://github.com/rust-lang/regex/blob/master/src/literal/mod.rs#L409-L540 https://github.com/rust-lang/regex/blob/master/src/literal/m... In Go-land, you should be able to replace uses of memchr with IndexByte[1], which should be implemented in Assembly on most platforms. Of course, for any of this to have a big impact, you'll want to take Mike Haertel's advice on avoiding line breaking and stop using bufio.Scanner. :-) [1] - https://golang.org/pkg/bytes/#IndexByte https://golang.org/pkg/bytes/#IndexByte
- arsham 8y agoSo far I've been only concerned about code's simplicity until I understand what there needs to be done. This is not going to be grep or ripgrep. My intent was to make a tool I needed so I started working on it. I thought someone else might like it, now it is joyful to see people are looking at the project. There are a couple of places I wish I would have done better. Using bufio.Scanner actually bothers me a lot. Also in the Read() method it reads everything from all readers into a buffer instead of pulling what it needs to check. Thanks for suggestions :)
- valarauca1 8y agoI’m doubtful ag and rg use a lot of smart optimizations to get their speed.
- deckarep 8y agoUmmm...your kidding right? I know ripgrep has a ton of fantastic optimizations by Burntsushi. You might wanna check it out...before making such statements.
- dagenix 8y agoI could be wrong, but I read valarauca1's comment as "I’m doubtful. ag and rg use a lot of smart optimizations to get their speed."
- mlevental 8y agolol people's reading comprensión is so bad sometimes
- laumars 8y agoIn 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).
- mlevental 8y agocontextualization is a component of reading comprehension
- laumars 8y agoThe 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.
- nazri1 8y agoI'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.
- JackCh 8y ago> "to make it easier to spot for the human eyes," I suppose in that sense it does aim to be fast. Fast for the human to parse.
- lillesvin 8y agoAs much as I love `ag`, I feel like ripgrep (https://github.com/BurntSushi/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/ https://blog.burntsushi.net/ripgrep/
- VeejayRampay 8y agoripgrep is soooooo good. I have switched to it and will never look back.
- sliken 8y agoI'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.
- arsham 8y agoThank you for doing the comparison. Would you do the same against the latest version (v0.5.0) please? Thank you.
- abstractbeliefs 8y agoDo be sure to at least consider supporting no colour! http://no-color.org http://no-color.org
- gitgud 8y agoWhat a great idea for a standard, so the tool will check the NO_COLOR environment variable, to see if it should display color.
- barrowclift 8y agoGenuinely 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.
- rektide 8y agoI don't find that they add anything. I feel like they make it harder for me to do a coherent read of the screen, to suck in all the text & process it. I have my own mental algorithms to pick out relevant things, and having a bunch of glaringly contrasting blocks of color glaring out of the terminal at me just makes it harder to slurp in the screen. I don't want that segmentation. It's awful. 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.
- barrowclift 8y agoThat makes sense. In a way, it's like they're mental "speed bumps" that disrupt reading the text. I can certainly see why those "bumps" would be aggravating, thanks for the insight!
- vanattab 8y ago
- madmax96 8y agoUseless use of cat candidate.
- deleted 8y ago[deleted]
- axaxs 8y agoThere's a difference between useless and unnecessary, both in definition and how a reader views the statement.
- s17n 8y agoIt's clearly there to demonstrate the pipe support...
- dagenix 8y agoThis 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?
- local_host 8y agoThe alternative would be `blush "some text" FILENAME`, which would work with sudo.
- deleted 8y ago[deleted]
- hawski 8y ago
- grblovrflowerrr 8y agoReally cool! But from the title I initially thought this was a grep tool for finding certain colors in your image data.
- blockchain-help 8y agohttps://www.blockchainhelp.pro https://www.blockchainhelp.pro
- tex0 8y agoNice 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 https://github.com/dominikschulz/gg
- teekert 8y agoBut... Can it elegantly suppress broken pipe errors?
- arsham 8y agoHandling signals are not implemented yet. I appreciate it if you file an issue when you find any. Thanks.
- xab9 8y agoI 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 8y agoGNU grep has support for colors.
- kbd 8y agoPlease reread the examples, which are specifying multiple searches and custom colors for each type of match, something that GNU grep can't do.