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

191–200 of 219 posts

Re: Ripgrep – A new command line search tool

#191

Post by ajsalminen »

ggreer wrote: post #137
chrisshroba wrote: post #134

Earlier quoted context omitted.

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 th…

I do think it would be better to have the name at least reflect that class of applications, maybe "searchignore" like someone else suggested. There may be overlap but it's hard to predict all the types of applications people are using that need ignore functionality and something as simple as backing things up with rsync would seem like an example where someone could well want considerably different ignores.

Re: Ripgrep – A new command line search tool

#192

Post by burntsushi »

reubano wrote: post #188

Nice writeup! Any chance you'll support macports for those of us who never jumped ship to homebrew?

I'm not a mac user, so I'm terribly unfamiliar with the ecosystem. In principle, I have no problem with supporting macports, but I haven't looked into it.

One thing that would be a huge help is if someone briefly wrote up what would be necessary to get ripgrep into macports: https://github.com/BurntSushi/ripgrep/issues/10

Re: Ripgrep – A new command line search tool

#193

Post by skanga »

burntsushi wrote: post #182
luckman212 wrote: post #175

Earlier quoted context omitted.

The releases are right there on GitHub: https://github.com/BurntSushi/ripgrep/releases

I think the GP was asking about xsv, not ripgrep. There are binary releases for xsv though: https://github.com/BurntSushi/xsv/releases

Awesome. Thanks

Re: Ripgrep – A new command line search tool

#194

Post by skanga »

skanga wrote: post #193
burntsushi wrote: post #182

Earlier quoted context omitted.

I think the GP was asking about xsv, not ripgrep. There are binary releases for xsv though: https://github.com/BurntSushi/xsv/releases

Awesome. Thanks

PS: You might want to revise this verbiage in the README markdown file:

    Installing xsv is a bit hokey right now. Ideally, I could release binaries for Linux, Mac and Windows. Currently, I'm only able to release binaries for Linux because I don't know how to cross compile Rust programs.

Re: Ripgrep – A new command line search tool

#195

Post by Scaevolus »

ggreer wrote: post #166
petre wrote: post #156

Earlier quoted context omitted.

I've just installed ag. It defaults to case insensitive searches when the pattern is in lowercase. Is there a way to change this default? Perhaps a config file of some sort?

There's no config file for default options. You probably want to add an alias to your bash/zsh/fishrc: alias ag='ag -s' I tend to favor aliases over config files. It reduces complexity and improves startup time. Startup time may not seem like a big deal, but it really matters if you're running something like: find . -ctime 2 -exec ag blah (Find all files modified in the past two days and search them for instances of…

find can batch arguments using +, much like xargs:

    find . -ctime 2 -exec ag blah {} +
This makes startup latency less important.

Re: Ripgrep – A new command line search tool

#196

Post by glangdale »

I'm glad to see this work get written up. If anyone wants a good project, there are some optimizations we (the Hyperscan team) have done in our "Teddy" SIMD string implementation that aren't captured (yet) in the Rust implementation to my knowledge. We're very happy to see techniques from our library get used in other projects as one of the points of open sourcing it (https://github.com/01org/hyperscan) was to share how we do things with the community.

Re: Ripgrep – A new command line search tool

#198

Post by tedmielczarek »

burntsushi wrote: post #78
saurik wrote: post #47

Earlier quoted context omitted.

This would have been a lot more exciting if it were designed to actually be even slightly compatible with grep (or maybe had some core in there that was, while leaving the other UI parts he wants to change on top) and were then approaching GNU and saying "hey, this is something I've been working on: would you consider making grep the first standalone tool to move to Rust, and what would it take from me to make this h…

> (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 just wanted to say that I think you're doing great work here! Obviously everyone has their own motivations for doing open source work, and yours are clearly to work in Rust and contribute to the Rust community while also scratching some personal itches.

Honestly, I'm not sure that trying to contribute to grep would even be worthwhile. You've got a few cases where ripgrep is faster than grep, but to submit patches to grep to fix it for those cases would be an enormous amount of effort, and either require you to rewrite a whole bunch of Rust code in C or the grep maintainers to accept patches in Rust, neither of which seem like great ideas. What you have done is advance the state of the art in search tools, as well as provide lots of building blocks to the Rust community for other developers to get great behavior out of their own programs. (Incidentally this is one thing I love about Rust--it's very straightforward for someone to write a crate that implements something in an extremely optimized way but still presents an easy-to-use API for other developers.)

I haven't had an opportunity to use many of your crates in my Rust development yet (except byteorder!) but I'm excited that they exist and I can definitely see myself using them in the future.

Re: Ripgrep – A new command line search tool

#199

Post by nolemurs »

burntsushi wrote: post #149
nolemurs wrote: post #140

Earlier quoted context omitted.

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.

Other than using your .gitignore or .ignore files to ignore it, that is indeed the intended way to do it. Sadly, I have an embarrassing bug. Should be fixed soon: https://github.com/BurntSushi/ripgrep/issues/43

Ahh, fantastic. I just tried out the new build. It's a real joy to be able to do things like `rg pattern -g '!{docs,tests}/' -tpy` and have it just work. Honestly, all performance aside, your thoughtful choice of command line options is the big selling point for me. I struggle to find the command line flags I need to make `ag` do just what I want, but `rg` seems to fit my expectations without much training.

Re: Ripgrep – A new command line search tool

#200

Post by burntsushi »

nolemurs wrote: post #199
burntsushi wrote: post #149

Earlier quoted context omitted.

Other than using your .gitignore or .ignore files to ignore it, that is indeed the intended way to do it. Sadly, I have an embarrassing bug. Should be fixed soon: https://github.com/BurntSushi/ripgrep/issues/43

Ahh, fantastic. I just tried out the new build. It's a real joy to be able to do things like `rg pattern -g '!{docs,tests}/' -tpy` and have it just work. Honestly, all performance aside, your thoughtful choice of command line options is the big selling point for me. I struggle to find the command line flags I need to make `ag` do just what I want, but `rg` seems to fit my expectations without much training.

Thanks for your encouragement. It's really hard to stand my ground because so many people have so many different use cases. The design space is large and it's very challenging to get it even a little right.

In any case, your example is quite fortuitous, since the `{docs,tests}` glob syntax was also added in 0.2.0. :-)

Post reply on HN