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

Ripgrep – A new command line search tool

blog.burntsushi.net

Post reply on HN
Print view View original

131–140 of 219 posts

Re: Ripgrep – A new command line search tool

#131

Post by ggreer »

burntsushi wrote: post #128
ggreer wrote: post #103

Earlier quoted context omitted.

In terms of core features, ripgrep is totally there. It searches fast . It ignores files pretty accurately. It outputs results in a pleasant and useful format. If a new user tries rg, they'll be very happy. My warning about the feature differences was meant to temper ag users' expectations. There are lots of little things that ag users are accustomed to that are either different or missing in ripgrep. Off the top of…

You raise good points, thank you. I hope to support some of those features, since they seem like nice conveniences. In principle I'd be fine standardizing on a common ignore file. We'd need to come up with a format (I think I'd vote for "do what gitignore does", since I think that's what we're both doing now anyway). Adding files to this list is kind of a bummer though. I could probably get away with replacing `.rgig…

I also vote for "do what gitignore does". My plan is to add support for the new file name, deprecate .agignore, and update docs everywhere. But it'd be a while before I removed .agignore completely.

I really like .ignore, and I like it because it's generic. The information I want it to convey is:

> Dear programs,

> If you are traversing this directory, please ignore these things.

Of course, some programs could still benefit from having application-specific ignore files, but it'd cut down on a lot of cruft and repetition.

Re: Ripgrep – A new command line search tool

#132

Post by burntsushi »

saurik wrote: post #129
burntsushi wrote: post #78

Earlier quoted context omitted.

> (or maybe had some core in there that was, while leaving the other UI parts he wants to change on top) But I did! Have you looked at the dependency list of ripgrep? It's utterly filled with tons of tools that you can pick out and use in other projects for any purpose you like. I didn't mention this in the blog post because there's already too much there, but sure, here they are: memchr - Fast single byte search: ht…

> I'm sure five years from now, when I've moved on to other problems, someone will come along and beat ripgrep, and I can only hope that they write about it. :-) I contend that the world would be a much better place if instead of someone building a new tool which beats yours, they worked to improve your tool (which, at the point where you moved on, would hopefully have been granted to a body of separate maintainers,…

> I am apparently becoming extremely unpopular in these circles for expressing this opinion

To be really clear: I don't think your opinion is necessarily the problem. When I first read your comment, I typed up a response that I wasn't proud of. It wasn't nice because your comment wasn't nice. I had to step away from the computer and take a moment to put things back into focus to give you the response I did. It wasn't easy.

And really, my reaction to your comment had nothing to do with your opinion that we should try to collaborate more. That's a completely reasonable thing to hope for. But some of the things you said, or implied (about me personally), were really way way off, and I personally found them pretty insulting.

I get that you took my blog post as combative, so maybe you think the same about me. But you didn't ask for clarification, you just kind of dove right into the insults and assumptions and bad faith, and personally, I think that is just a really awful way to interact with other humans.

It's clear that we have different valuations on how to spend our time, and I really don't appreciate your implicit condescension. I also don't appreciate you telling me how I should spend my time. My free time is precious, and I want to spend it doing the things I find interesting. I don't want to work on a legacy code base, in C and spend enormous social resources pushing on one of the most established C projects in existence to switch to a new programming language. That does not sound like fun to me, and I want to work on something fun in my free time. `ripgrep` happened to be it. (N.B. Fun is not the only criterion, but it's a big one.)

> but a really important aspect of open source was about people collaborating towards a common effort to build high quality software

I've spent a huge portion of my free time in the past 2.5 years contributing to the Rust ecosystem. If that's not collaborating towards a common effort, then I don't know what is. `ripgrep` itself is barely a blip in that effort. All the stuff that went into building `ripgrep` that is freely available as other libraries? Yeah, that took a while.

Re: Ripgrep – A new command line search tool

#133

Post by theseoafs »

saurik wrote: post #130
theseoafs wrote: post #56

Earlier quoted context omitted.

The developer has already stated that they did not intentionally name the tool "RIP grep". Even if they did, who cares? Why do people making grep alternatives have to treat grep with an extreme, undue amount of respect?

Why claim GNU grep would get "extreme, undue" amounts of respect? Should not all collaborative projects be afforded some basic level of respect? What is the underlying meaning of entering a collaborative software development community (the world of open source) and feeling, as you do, that it would be an "extreme, undue" level of respect to not purposefully attack (as to explicitly reference your "even if they did")…

If you think a project is bad then you should be allowed to say so. I'm sure you have used a software tool that you have complained about despite the fact that it was open-source.

It's a bridge to far to directly attack people just for working on an open-source project, but the creator of this project did not do that, obviously.

Re: Ripgrep – A new command line search tool

#134

Post by chrisshroba »

burntsushi wrote: post #128
ggreer wrote: post #103

Earlier quoted context omitted.

In terms of core features, ripgrep is totally there. It searches fast . It ignores files pretty accurately. It outputs results in a pleasant and useful format. If a new user tries rg, they'll be very happy. My warning about the feature differences was meant to temper ag users' expectations. There are lots of little things that ag users are accustomed to that are either different or missing in ripgrep. Off the top of…

You raise good points, thank you. I hope to support some of those features, since they seem like nice conveniences. In principle I'd be fine standardizing on a common ignore file. We'd need to come up with a format (I think I'd vote for "do what gitignore does", since I think that's what we're both doing now anyway). Adding files to this list is kind of a bummer though. I could probably get away with replacing `.rgig…

I really like .grepignore as it is generic enough to encompass all tools which have grep-like functionality while never stepping on the feet of other programs that may also require ignore files that may be different than the .grepignore.

Re: Ripgrep – A new command line search tool

#135

Post by burntsushi »

ggreer wrote: post #131
burntsushi wrote: post #128

Earlier quoted context omitted.

You raise good points, thank you. I hope to support some of those features, since they seem like nice conveniences. In principle I'd be fine standardizing on a common ignore file. We'd need to come up with a format (I think I'd vote for "do what gitignore does", since I think that's what we're both doing now anyway). Adding files to this list is kind of a bummer though. I could probably get away with replacing `.rgig…

I also vote for "do what gitignore does". My plan is to add support for the new file name, deprecate .agignore, and update docs everywhere. But it'd be a while before I removed .agignore completely. I really like .ignore, and I like it because it's generic. The information I want it to convey is: > Dear programs, > If you are traversing this directory, please ignore these things. Of course, some programs could still…

Let's do it. https://github.com/BurntSushi/ripgrep/issues/40

Re: Ripgrep – A new command line search tool

#136

Post by pohl »

losvedir wrote: post #29

Meh, yet another grep tool.... wait, by burntsushi! Whenever I hear of someone wanting to improve grep I think of the classic ridiculous fish piece[0]. But when I saw that this one was by the author of rust's regex tools, which I know from a previous post on here, are quite sophisticated, I perked up. Also, the tool aside, this blog post should be held up as the gold standard of what gets posted to hacker news: detai…

Another burntsushi project was recently posted, but didn't get much attention:

https://news.ycombinator.com/item?id=12559515

Re: Ripgrep – A new command line search tool

#137

Post by ggreer »

chrisshroba wrote: post #134
burntsushi wrote: post #128

Earlier quoted context omitted.

You raise good points, thank you. I hope to support some of those features, since they seem like nice conveniences. In principle I'd be fine standardizing on a common ignore file. We'd need to come up with a format (I think I'd vote for "do what gitignore does", since I think that's what we're both doing now anyway). Adding files to this list is kind of a bummer though. I could probably get away with replacing `.rgig…

I really like .grepignore as it is generic enough to encompass all tools which have grep-like functionality while never stepping on the feet of other programs that may also require ignore files that may be different than the .grepignore.

The problem is that grep will never obey .grepignore. That's so confusing as to be a deal-breaker.

Also, what about programs that have search functionality as part of their design, but not as their core function? For example, I don't want my text editor to search .min.js files. I'd even prefer it if such files didn't show up in my editor's sidebar. Do I have to add *.min.js to .searchignore and .atomignore? (Or if the editor people ever work out a standard, maybe it will be .editorignore.)

If I had to draw a Venn diagram of ignore patterns in my text editors, my search tools, and my rsync scripts, they'd mostly overlap. I don't deny the need for application-specific ignores, but there is a large class of applications that could benefit from a more generic ignore file.

Re: Ripgrep – A new command line search tool

#138

Post by JoshTriplett »

ggreer wrote: post #63

I'm the author of ag. That was a really good comparison of the different code searching tools. The author did a great job of showing how each tool misbehaved or performed poorly in certain circumstances. He's also totally right about defaults mattering. It looks like ripgrep gets most of its speedup on ag by: 1. Only supporting DFA-able Rust regexes. I'd love to use a lighter-weight regex library in ag, but users are…

> 1. Only supporting DFA-able Rust regexes. I'd love to use a lighter-weight regex library in ag, but users are accustomed to full PCRE support. Switching would cause me to receive a lot of angry emails. Maybe I'll do it anyway. PCRE has some annoying limitations. (For example, it can only search up to 2GB at a time.)

The standard trick here is to use the faster method for searches that it supports, and use the slower but more capable method only for searches that require it. Parse the regex, see if a DFA will work, and only use PCRE for expressions with backreferences and similar.

Re: Ripgrep – A new command line search tool

#139

Post by ggreer »

burntsushi wrote: post #135
ggreer wrote: post #131

Earlier quoted context omitted.

I also vote for "do what gitignore does". My plan is to add support for the new file name, deprecate .agignore, and update docs everywhere. But it'd be a while before I removed .agignore completely. I really like .ignore, and I like it because it's generic. The information I want it to convey is: > Dear programs, > If you are traversing this directory, please ignore these things. Of course, some programs could still…

Let's do it. https://github.com/BurntSushi/ripgrep/issues/40

…and merged: https://github.com/ggreer/the_silver_searcher/pull/974

I'll tag a new release in a day or two. Also, it looks like the sift author is getting on the .ignore train: https://github.com/svent/sift/issues/78#issuecomment-2493352...

This worked out pretty well. :)

Re: Ripgrep – A new command line search tool

#140

Post by nolemurs »

burntsushi wrote: post #84
nolemurs wrote: post #44

Earlier quoted context omitted.

`grep` itself is admirably fast on single files, and if you're just searching a small number of files, the bottleneck will be IO, and `grep` will be about as fast as anything. But if you want to use `grep` recursively on a selected subset of millions of files it suffers a bit. `grep` assumes that if you want to collect some subset of files to search, you'll do that with some other utility, and pass the list of files…

> and `grep` will be about as fast as anything I'd encourage you to check out the benchmarks in my blog, especially the subtitle benchmarks, because this isn't actually true in the case of ripgrep. :-)

I take it back! I'm definitely switching over to using ripgrep for the next bit.

Off topic - is there a way to exclude directories? I tried doing things like `rg pattern -g '!my_dir/' but nothing I tried seemed to work.

Post reply on HN