Best grep-like tool

Question

I do in file search a lot, and used to love grep. Then I learn the existence of egrep, so I switched to benefit from the advanced regexp. Then I discovered the Eclipse search tool. Much easier to use that grep. Then I found ack : fast, easy, powerful. And now I use grin, which is smooth for pythonistas. I know there is also a couple of this kind of tools with a GUI.

So what tool do you use, and why do you think it's the best. Practical features generally are :

• fast to fire and use;
• speedy processing;
• automatically ignore useless files;
• colored output;
• output lines, filename, context;
• allow complex regexp;
• allow a custom filtering and ouput;
• GUI + command line intergation;
• let you open an editor from the result set.

There are some related posts on SO :

• http://stackoverflow.com/questions/87350/what-are-good-grep-tool-for-windows
• http://stackoverflow.com/questions/981601/colorized-grep-viewing-the-entire-file-with-highlighting
• http://stackoverflow.com/questions/1028107/is-there-some-unix-util-that-will-allow-me-to-grep-multiple-files-with-little-type
• http://stackoverflow.com/questions/1027906/unix-find-grep-syntax-vs-awk

Answer 1

Personally, I've always gone with ack. Does grin presently have any advantages over ack?

Answer 2

Findstr works great if you have a Windows machine

Answer 3

See

• Grep GUI
• V-Grep
• NthGrep

Answer 4

On Windows I use the GREP function built into RegexBuddy which lets you build and test your regex within the GUI. The same company also do the much more expensive PowerGREP which I haven't tried.

Answer 5

PowerGREP does all this, and more. Awesome tool (as already mentioned in one of the posts you linked).

Answer 6

Ack is very popular, although I don't like it, because with a single line of config, grep does everything it does, and is actually faster, despite ack's loud claims to the contrary:

$ cat `which grp`
#!/usr/bin/env bash
grep -rI --color --exclude-dir=\.bzr --exclude-dir=\.git --exclude-dir=\.hg --exclude-dir=\.svn --exclude-dir=build --exclude-dir=dist --exclude=tags $*

I did this once in the 1980s, and since then grep does everything that ack does. (I have some python-specific excludes in there. No doubt you'll choose some idiosyncrasies of your own as you work.)

You could use an alias instead of a script, but I like to create an executable script like this, then I can invoke it from other programs like vim, so that my search within vim works just like my searches at the command-line. You shouldn't use the GREP_OPTIONS environment variable, because this affects all invocations of grep, even those embedded within other tools, which may break those tools.

Since grep uses blacklists (as specified above) instead of whitelists, it doesn't unexpectedly omit correct results like ack does. I worry that ack would miss occurences in filetypes it doesn't know about, like extensionless files such as cronfiles or Makefiles, which could be named anything. Is this a valid worry, or does it never happen somehow?

If you set up a handful of common blacklists to be used as default (e.g. skip '.git' directories and -I to skip binary files) then grep is actually faster, despite ack's loud claims to the contrary.

Grep will highlight matches in --color.

Grep will recurse into subdirs (-r)

In short, almost every single one of the 'reasons to prefer ack' listed on its homepage are actually undesirable, misleading or downright untrue. Grep does everything ack does, better and faster, plus with decades of bugfixes and optimizations and compatibility and a community of knowledge. The whole Ack project is a massive waste of time that should never have been created.