4 ms·

For grepping, rg is faster and saner. https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep On end-user systems with fast I/O, it is usu

For grepping, rg is faster and saner. https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep On end-user systems with fast I/O, it is usually a better use of resources to have a battery-/suspend-/reboot-aware indexing system that has path/extension white/blacklists and prioritizes file monitored changes. This way, searching can happen against an optimized text search DBMS much faster than waiting for zillions of IOPS that are basically wasted by instead spending them ahead-of-time in the background/idle indexing text files/metadata/structured data once when it changed/s and already know exactly where all occurrences of kWhateverCondition_PP3V42_G3H or \A[AB]{1,3}c+d\z live under ~/Projects without reading any actual files.

eikenberry 7y ago
Do either of these tools have a "grep" mode, so that I can alias grep to it and get similar, but improved, behavior? 25 years of habit is a lot of reinforcement to overcome and I'd love to just be able to take advantage of these tools with an alias. As is I just have a grep wrapping shell script to give it some sane defaults which works fairly well.
- anonsivalley652 7y ago
  No, you're asking oranges to be bananas. Read the man page or user guide. It's not grep, it's better and already has saner defaults. https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md
- ryannevius 7y ago
  The closest I know of is `rg -uuu`. From the manual: > -u, --unrestricted ... > Reduce the level of "smart" searching. A single -u won't respect .gitignore (etc.) files. Two -u flags will additionally search hidden files and directories. Three -u flags will additionally search binary files. > rg -uuu is roughly equivalent to grep -r.
- burntsushi 7y ago
  Author of ripgrep here. > As is I just have a grep wrapping shell script to give it some sane defaults which works fairly well. Yes, that's what I did for about ten years before I wrote ripgrep. :-) > Do either of these tools have a "grep" mode, so that I can alias grep to it and get similar, but improved, behavior? Another commenter already mentioned `rg -uuu`, and that's pretty much the right answer. In a large number of cases, if you `alias grep=rg`, then most things will continue to work as you expect. If you really do not want any kind of smart filtering, then yes, you'll want `alias grep="rg -uuu"`. But otherwise, things like `command ... | rg pattern` and `rg pattern file ...` will continue to work just like grep. ripgrep also tries to use the same names for flags as grep, wherever possible. So you'll find a lot of overlap there too. Please note that ripgrep is not and is not intended to be a drop-in replacement. But I didn't go out of my way to be incompatible with grep either. So a lot of it should be quite familiar!
svnpenn 7y ago
Yeah and its also 10 times larger https://github.com/BurntSushi/ripgrep/issues/1481 https://github.com/BurntSushi/ripgrep/issues/1481
- detaro 7y ago
  the previous issue on the topic has some pointers
- dharmab 7y ago
  Which is absolutely a good trade-off for a modern desktop system.
- reificator 7y ago
  If you go on a system with grep aliased and run your single grep command, are you going to be able to tell which binary was larger? If you look at the size of two disk images for different distros, and one has grep while the other has ripgrep, are you going to be able to tell which is which? 10x larger than grep is noise in 2020. Making that tradeoff in exchange for significantly improved performance seems reasonable. Not to mention a large part of that difference is likely due to grep relying on libc, while ripgrep has to bundle its own runtime. And that's not even bringing up memory safety. I'll take ripgrep at 10x the size of grep any day.
- burntsushi 7y ago
  Yes. If that disk space is more important to you than correctness, performance and better Unicode support, then yeah, you should definitely keep using the silver searcher. I gave more details in a response on that issue: https://github.com/BurntSushi/ripgrep/issues/1481#issuecomment-583844339 https://github.com/BurntSushi/ripgrep/issues/1481#issuecomme...

eikenberry 7y ago

Do either of these tools have a "grep" mode, so that I can alias grep to it and get similar, but improved, behavior? 25 years of habit is a lot of reinforcement to overcome and I'd love to just be able to take advantage of these tools with an alias. As is I just have a grep wrapping shell script to give it some sane defaults which works fairly well.

anonsivalley652 7y ago
No, you're asking oranges to be bananas. Read the man page or user guide. It's not grep, it's better and already has saner defaults. https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md
ryannevius 7y ago
The closest I know of is `rg -uuu`. From the manual: > -u, --unrestricted ... > Reduce the level of "smart" searching. A single -u won't respect .gitignore (etc.) files. Two -u flags will additionally search hidden files and directories. Three -u flags will additionally search binary files. > rg -uuu is roughly equivalent to grep -r.
burntsushi 7y ago
Author of ripgrep here. > As is I just have a grep wrapping shell script to give it some sane defaults which works fairly well. Yes, that's what I did for about ten years before I wrote ripgrep. :-) > Do either of these tools have a "grep" mode, so that I can alias grep to it and get similar, but improved, behavior? Another commenter already mentioned `rg -uuu`, and that's pretty much the right answer. In a large number of cases, if you `alias grep=rg`, then most things will continue to work as you expect. If you really do not want any kind of smart filtering, then yes, you'll want `alias grep="rg -uuu"`. But otherwise, things like `command ... | rg pattern` and `rg pattern file ...` will continue to work just like grep. ripgrep also tries to use the same names for flags as grep, wherever possible. So you'll find a lot of overlap there too. Please note that ripgrep is not and is not intended to be a drop-in replacement. But I didn't go out of my way to be incompatible with grep either. So a lot of it should be quite familiar!

svnpenn 7y ago

Yeah and its also 10 times larger https://github.com/BurntSushi/ripgrep/issues/1481 https://github.com/BurntSushi/ripgrep/issues/1481

detaro 7y ago
the previous issue on the topic has some pointers
dharmab 7y ago
Which is absolutely a good trade-off for a modern desktop system.
reificator 7y ago
If you go on a system with grep aliased and run your single grep command, are you going to be able to tell which binary was larger? If you look at the size of two disk images for different distros, and one has grep while the other has ripgrep, are you going to be able to tell which is which? 10x larger than grep is noise in 2020. Making that tradeoff in exchange for significantly improved performance seems reasonable. Not to mention a large part of that difference is likely due to grep relying on libc, while ripgrep has to bundle its own runtime. And that's not even bringing up memory safety. I'll take ripgrep at 10x the size of grep any day.
burntsushi 7y ago
Yes. If that disk space is more important to you than correctness, performance and better Unicode support, then yeah, you should definitely keep using the silver searcher. I gave more details in a response on that issue: https://github.com/BurntSushi/ripgrep/issues/1481#issuecomment-583844339 https://github.com/BurntSushi/ripgrep/issues/1481#issuecomme...