18 ms·
Feature comparison of ack, ag, git-grep, GNU grep and ripgrep
- markild 9y agoNot exactly sure what it is, but I really like this presentation format. Thank you, have been trying to motivate myself to switch to ack/ag for a while. This seems like it might be what I needed.
- metalliqaz 9y agoGood use of color as well as a visual reference for when the tools share a feature. I agree it's a good presentation. As for search, I'm on Windows and I like to use FileLocator Pro.
- nolemurs 9y agoConsider just switching to ripgrep instead. It's faster, and the default flags and interface are more thoughtful. This chart may make it seem less feature rich, but most of the 'features' it's missing are thing you'll never need, or things that your shell should be responsible for ("Pipe output through a pager or other command"?). The only serious feature you might miss is lookahead/lookbehind in regexes - that's missing by design since if you want guaranteed linear time search you can't have those.
- derwiki 9y ago> "Pipe output through a pager or other command" I really like the discussion that lead to the decision of never including a pager: https://github.com/BurntSushi/ripgrep/issues/86 https://github.com/BurntSushi/ripgrep/issues/86
- nothrows 9y agoas a long time user of `find . -name "*.foo" -exec grep -Hin {} \;` moving to ack has been great! I love the syntax and the speed and the fact that it actually respects your ignore files. ripgrep is great too. ag on the other hand is recommended by everyone but doesn't seem to respect ignores or understand modern ignore syntax. give it a pass. https://github.com/ggreer/the_silver_searcher/issues/385 https://github.com/ggreer/the_silver_searcher/issues/385 its been over 4 years... its had its chance.
- kstrauser 9y agoI love ag for one purpose: as a lightning quick “find other instances of the currently highlighted word” helper for Emacs. It’s great for that.
- xorcist 9y agoSpawning a separate grep for each file? That's terribly inefficient. At least use xargs which will run one process on as many files as possible. But you know there's a -r for recursive, right? And unless you are using some historic relic of grep that is not GNU or BSD and doesn't understand the --include option you can just do: grep -rin "needle" --include "*.foo" .
- aidenn0 9y agoI use something along the lines of find . -iname '.*' -prune -o -iname '*.foo' -exec grep needle {} + I don't want to have to learn 10 different command syntaxes for walking directory trees, so find works well. The "+" terminator of find's exec is similar to xargs, but preserves the flexibility of find's exec.
- fragmede 9y agoAt the least, I recommending moving past `find . --name '*.foo' -exec grep` pattern if you can help it. Modern file searchers, of which `ag` is one among others, accepts `--filenametype` argument and skips the `.git` subdirectory if it exists (by default, can be toggled), so `ag --python needle` will recursively search for needle in the the current working tree in all files whos filenames end in `.py`. Yes, you could write a function to do the same in `find`, but then you're just being stubborn. (Which is fine; my .bashrc is littered with aliases and functions of me being stubborn, but if I have to copy my .bashrc file around, I might as well install my preferred searcher to the target system if available.)
- xorcist 9y agoOr just use "grep". It is what it's there for. Use --include and --exclude-dirs to do what you describe. (The latter is a good idea to set in your GREP_OPTIONS, unless you actually search .git directories.)
- caio1982 9y agoWhat has always amazed me is how super fast ack is in my use cases.
- dh-g 9y agoswitched from ag to rg a few months ago and have nothing but good things to say about the experience.
- hivacruz 9y agoI made the switch too (from grep to rg). I really like it so far. It is a little more faster than grep for my use!
- nialo 9y agoI switched also recently, the thing that helped me was adding this: alias rg='rg -S' to my .bashrc so that rg had the same default case sensitivity as ag.
- rektide 9y agoI do wish the persistent config file enhancement had a significant chance of becoming a reality. https://github.com/BurntSushi/ripgrep/issues/196 https://github.com/BurntSushi/ripgrep/issues/196 I understand alias'es and wrappers fine, but I like having the environment have some way to contribute. It's just my simple preference. There's also the related #314 which makes even more sense- per project configuration. Sure would be great being able to download a project & have it already setup nicely for ripgrep! https://github.com/BurntSushi/ripgrep/issues/314 https://github.com/BurntSushi/ripgrep/issues/314
- burntsushi 9y ago> I do wish the persistent config file enhancement had a significant chance of becoming a reality. As the ticket says (I think), tt's going to happen. It's just a lot of tedious work.
- rektide 9y agoWow, cool. Thanks burntsushi. rg is already amazing. This project really has gotten an enormous amount of love & effort from you & it really shows through & through. Your implementation of the gitignore algorithm is crazy impressive to me.
- infodroid 9y agoThe chart was created by Andy Lester, the creator of ack, who thinks that more open source projects should point to their "competing" projects because it's not really a competition: http://blog.petdance.com/2018/01/02/the-best-open-source-project-for-someone-might-not-be-yours-and-thats-ok/ http://blog.petdance.com/2018/01/02/the-best-open-source-pro...
- SamPutnam 9y agoEmphasis mine- Excerpt: "Some might say that ag and ripgrep and any of the other tools I list on beyondgrep.com are competing projects, but I think that way of thinking is wrong. It’s only a competition if you see it as a competition. I’m not competing against anyone for anything: Clicks, dollars, popularity, etc. If someone uses ripgrep instead of ack, it doesn’t hurt me. It’s the difference between an abundance vs. scarcity view of the world. I choose abundance. I think most of us who work in open source do, too." I never thought I would see the confluence of the "woo-woo" space abundance mindset and a blog post about an open source command-line utility. I must say I am intrigued. If this explanatory medium doesn't substantiate the reasonability of a mindset of abundance in the minds of programmers, I don't know what ever will.
- bringtheaction 9y agoWhat is woo-woo space?
- girvo 9y agoI’d wager they’re talking about the whole “The Secret” abundance mentality thing. “Believe and you shall receive... somehow”. That sort of interesting New Age stuff. I put no credence in it myself in terms of their stronger claims, but hey, CBT reminds me of it in a lot of ways and helped cure my depression.
- pantalaimon 9y agoYour view on the world shapes how you perceive the world (yes I've learned that in the tautology club) and as your reality is only what perceive, your view on reality shapes how you see it. Not much woo woo involved.
- the_mitsuhiko 9y agoI’m stuck with rg right now because it’s the only ine which correctly handles gitignore files. Generally quite happy with it but I wish it could also use a more powerful regex engine for some less common cases. Most annoying thing is that $ does not work with windows newlines.
- jrochkind1 9y agoack doesn't do git ignore right? The matrix suggests it does, and I thought it did, but I don't use it routinely.
- the_mitsuhiko 9y agoIt supports a subset but not a very good one. At least it fails to handle leading slashes.
- petdance 9y agoack does not look in .gitignore files at all.
- andersonfreitas 9y agoHave you tried sift? https://sift-tool.org/ https://sift-tool.org/
- burntsushi 9y agosift addresses neither of the GP's concerns with ripgrep. It's also much much slower than ripgrep on almost anything other than simple literal scans.
- hashkb 9y agoI've been using pt for a few years... am I dumb or do I have a secret?
- burntsushi 9y agoNeither. pt is part of the benchmark suite I published when I introduced ripgrep[1]. TL;DR - It's fast for simple literal searches, but that's it. [1] - http://blog.burntsushi.net/ripgrep/ http://blog.burntsushi.net/ripgrep/
- coldtea 9y agorg for the win. It's not some huge improvement, but it's more of a feeling that things just work by default (similar to what I get from tmux vs screen).
- mhd 9y agoI've got the reverse feeling recently, as ag does smartcase searching by default and rg doesn't...
- nolemurs 9y ago`alias rg='rg -S'` in your `.bashrc` will fix that for you. Out of curiosity, what sort of searches do you do that smartcase is desirable? A meaningful number of people seem to prefer it, but I find that most of the time I want to be able to search for variables etc. case sensitively.
- mhd 9y agoWe were talking about defaults and feelings here, I'm aware that it's easy enough to fix (and to be fair, I now often use ripgrep with the inverse alias)… I'm generally a big fan of smartcase. Most of the time I don't care about case and it's easier to type it that way, and when I care, it's often mixed or upper case, so smartcase Does What I Mean. And for the few times when I explicitly search for all-lowercase, it's easy enough to turn it off (M-c, -s, :set nosmartcase etc.).
- petdance 9y agoI added smartcase in ack because I used it constantly in vim. I don't normally want to have to remember if the function I'm searching for is "format_ISBN" or "format_isbn", for example. Some languages (PHP) aren't always case-sensitive, so you need to search both. I'd rather use a "-I" in the few cases where I don't want case-sensitive, than having to remember to add "-i" in the 99% of the cases where I don't.
- mbroshi 9y agoNice feature-level comparison. Don't know how you'd pull it off in the current tabular format, but would be great to include some of the UX side of things: For example, I use rg almost exclusively because it has an easy-to remember syntax (`rg search-string` is a recursive search), attractively colored and well-organized output, and seems much faster compared to other tools in my use cases.
- memco 9y agoSeems pretty comprehensive. One confusing thing I found was these two: "Don't respect ignore files (.gitignore, .ignore, etc)" vs "Skip rules found in VCS ignore files (.gitignore, .hgignore, etc)" Aren't those the same thing? Shouldn't they be grouped for better comparison?
- rozim 9y agoThe table is misleading isn't it? It seems to imply that rg can't work recursively, but [1] states "..ripgrep defaults to recursive directory search...". I understand that the table might mean that rg doesn't have a flag to enable recursive search, but surely we care about features more than flags... [1] https://github.com/BurntSushi/ripgrep#why-should-i-use-ripgrep https://github.com/BurntSushi/ripgrep#why-should-i-use-ripgr...
- infodroid 9y agoThe table doesn't yet distinguish between lacking a command line flag due to absence of a feature vs due to the feature being the default. This is similar to the situation with case-sensitive search in GNU grep, which ends up with a blank cell even though it is the default. See: https://github.com/beyondgrep/website/issues/72 https://github.com/beyondgrep/website/issues/72 It's a fair criticism but I don't think it is designed to be misleading.
- fragmede 9y agoMaybe not designed to be misleading, but misleading nonetheless. For `grep`, `grep -i needle` is (approximately) equal to `ack/ag needle`, but looking at the table I wouldn't think grep supports case sensitivity.
- petdance 9y agoI've updated the phrasing so it says "Re-enable case-sensitive search over case-insensitve or smart-case search".
- bluGill 9y agoI agree, but I know in my own project that my "competition" is moving, and I don't follow them. Thus any time like the linked one that I create quickly become out of date as they add new features.
- wyldfire 9y agoIt's almost more useful as a rosetta stone than a feature comparison.
- petre 9y agoAck and ag use Perl/PCRE so they're more useful than grep/rg if you know Perl style regular expressions.
- avar 9y agoGNU grep supports PCRE as well.
- fphilipe 9y agoA nice feature of ag is the ability to limit the search to a certain file type. E.g. to only search ruby files: ag --ruby foo. To see a list of supported types and the matching file extensions: ag --list-file-types. Just checked and rg does have something similar, but you need to specify the type as an argument to a flag: rg --type ruby foo.
- petdance 9y agoack does the "limit by a certain filetype", and it also lets you define your own file types or extend existing ones. ag does not.
- okdana 9y agoYou can shorten it with -t: -tc, -tphp, -truby, -tsh. Then it's actually the same amount of characters as with ag.
- masklinn 9y agoAnd has the advantage of being pluggable rather than a hard-coded list of file types (though IIRC ack has a configuration file whereas with rg you need to use an alias to set up new types for every invocation).
- petdance 9y agoack has a configuration file, and it's extremely flexible, including the ability to check shebang lines. If you have a shell script without an extension, it's the only way to know what language it is.
- adamnemecek 9y agoThis chart doesn't compare speed. Until rg, I didn't grep much because I generally search through a lot of files. rg cuts through them in no time.
- petdance 9y agoNo, the chart doesn't compare speed. Lord knows there have been many comparisons of the speeds of grep-alikes, but nobody has written up a comparison of features. For me, raw speed is not as important as a rich feature set to support my code spelunking.
- andersonfreitas 9y agoThe `sift` [1] tool presents a performance comparison, but not against `rg`. [1] https://sift-tool.org/performance https://sift-tool.org/performance
- burntsushi 9y agoripgrep's introductory blog post[1] includes a perf comparison, which incorporates sift. But sift is too slow to include in several benchmarks. sift's achievement is its fast parallel directory traverser, coupled with Go's vectorized IndexByte[2] function for simple literals. In that case, it is quite fast, but as soon as you enter Go's regex engine, it's game over. [1] - http://blog.burntsushi.net/ripgrep/ http://blog.burntsushi.net/ripgrep/ [2] - https://golang.org/pkg/bytes/#IndexByte https://golang.org/pkg/bytes/#IndexByte
- BlackFingolfin 9y agoUnfortunately that page does not say when the comparison was made, and which version of each tool was tested. Also, which "grep" is that? I assume GNU grep? There are others, though... All in all, it'd still be nice to have a more comprehensive performance comparison page, which gets regularly updated. Bonus points if it shows how speed changes over time, similar to http://speed.pypy.org http://speed.pypy.org (the code for that is available, by the way). Wishful thinking, I know, but hey, who knows... :-)
- zellyn 9y agoHere to plug using `--passthru`/`--passthrough`: it will print all lines, but highlight matches. I often do things like this to watch an output log, but highlight all entries with the string PLUGH in them: tail -F output.log | ag --passthrough '.*PLUGH.*'
- CJefferson 9y agoI wondered what that option could be useful for, thanks!
- okdana 9y agoYou can achieve that in almost any of these tools (including old-school grep) by matching against something with zero width, like this: grep '^|.*PLUGH.*'
- petepete 9y agoYou could do that. Or you could just use --passthrough. It's easy to remember, easy to type, it autocompletes, it doesn't interfere with your criteria.
- whacker 9y agoThe equivalent in grep is '--line-buffered'.
- richardwhiuk 9y agohuh?
- whacker 9y agoI mean you can use grep as a filter for tail -f output.
- palotasb 9y agoThat's an orthogonal feature, it writes output after each line as opposed to every 4096 bytes, when the output is a pipe instead of a terminal. Useful when the other end of the pipe still goes to the terminal and you want to see it immediately. If `some-util-with-output` echoes stdin then without the option the following would not show you the latest grepped lines until the 4096 buffer fills. tail -F output.log | grep --line-buffered TEXT | some-util-with-output
- visarga 9y agoAny modern tools like this? sary - a suffix array library and tools http://sary.sourceforge.net/ http://sary.sourceforge.net/ It finds words in O(log(n)) time by using an additional index.
- burntsushi 9y agoThe problem with suffix arrays---even with a blazing fast SACA---is that they are slow. It will take a long time to generate an index for even a moderately sized code repository. Typically, if you want an index, you build an inverted index, which maps terms (e.g., n-grams or tokens in your favorite PL) to a postings list. The postings list contains all of the documents in which that term occurs.
- akerro 9y agoThe table somehow missed MIT grep.
- satish-setty 9y agoSeems everybody here has switched to rg but I haven't because it's not available in Debian repos (yet) unlike ack/ag. So, do such folks use Arch or just download a pre-built binary ? How about updating rg when a new version is out ?
- cesarb 9y agoThe easiest way: first, install rust and cargo, either through your distribution, or thorough rustup if your distribution doesn't have it yet. Then run "cargo install -f ripgrep". It'll download the source code, build, and install to ~/.cargo/bin, which rustup adds to $PATH for you by default. Edit: the "-f" in the "cargo install" command is for updating; without the -f, it refuses to install over an already installed version. The first time you install, you can omit the -f.
- burntsushi 9y agoNote that if you install Rust through Debian, it likely won't be new enough to compile the latest version of ripgrep. I believe Debian packages Rust 1.14, and the last version of ripgrep to work on Rust 1.14 was 0.5.2. So, `cargo install --vers 0.5.2 ripgrep` might be what you want on Debian.
- glandium 9y agoDebian stable has 1.14, but Debian testing has 1.22.1.
- sedachv 9y agorg has been in OpenBSD packages since 6.1
- masklinn 9y ago> No descending into subdirectories > Limit directory search depth These could be the same item, the former is a special case of the latter.
- iameli 9y agoMissing `git grep --name-only`
- petdance 9y agoThere's a link to the issue tracker right there at the top of the page.
- arca_vorago 9y agoThe one thing I wish more of these comparison tables had was licensing info, so for those like me who are curious: 1. GNU grep - GPLv3+ 2. ack - Artistic License v2.0 3. ag (aka silver searcher) - Apache License 2.0 4. git-grep - GPlv2+/LGPLv2.1+ 5. rg - MIT license So with maybe the exception of rg, all are gpl compatible, that's great news.
- burntsushi 9y agoAnything that is permissively licensed (like ripgrep) is generally GPL compatible.[1] Note also that ripgrep is dual licensed under the Unlicense or the MIT license, both of which are explicitly GPL compatible according to [1]. [1] - https://www.gnu.org/licenses/license-list.en.html https://www.gnu.org/licenses/license-list.en.html
- petdance 9y agoI'm going to be making a new chart that is more about features than command flags. I'll include the licensing information. Thanks. https://github.com/beyondgrep/website/issues/80 https://github.com/beyondgrep/website/issues/80