As is I just have a grep wrapping shell script to give it some sane defaults which works fairly well.
> 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!
> -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.
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.
I gave more details in a response on that issue: https://github.com/BurntSushi/ripgrep/issues/1481#issuecomme...
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.