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

Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

beyondgrep.com

Post reply on HN
Print view View original

21–30 of 101 posts

Re: Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

#21

Post by nolemurs »

markild wrote: post #2

Not 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.

Consider 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.

Re: Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

#22

Post by rozim »

The 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-ripgr...

Re: Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

#23

Post by nolemurs »

mhd wrote: post #19
coldtea wrote: post #15

rg 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).

I've got the reverse feeling recently, as ag does smartcase searching by default and rg doesn't...

`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.

Re: Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

#25

Post by derwiki »

nolemurs wrote: post #21
markild wrote: post #2

Not 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.

Consider 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 mis…

> "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

Re: Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

#26

Post by infodroid »

rozim wrote: post #22

The 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-ripgr...

The 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

It's a fair criticism but I don't think it is designed to be misleading.

Re: Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

#27

Post by fragmede »

nothrows wrote: post #3

as 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 its been over 4 y…

At 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.)

Re: Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

#28

Post by jrochkind1 »

the_mitsuhiko wrote: post #9

I’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.

ack doesn't do git ignore right? The matrix suggests it does, and I thought it did, but I don't use it routinely.

Re: Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

#29

Post by fragmede »

infodroid wrote: post #26
rozim wrote: post #22

The 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-ripgr...

The 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 It's a fair criticism but I don't think it is designed to be misleading.

Maybe 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.

Re: Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

#30

Post by bluGill »

rozim wrote: post #22

The 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-ripgr...

I 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.
Post reply on HN