ack-grep - a source-aware grep replacement (searching for content in files)
Link: http://petdance.com/ack/
ack (or ack-grep) is a nice "grep" replacement, when searching in a directory with source files.
It does not require any path to start searching and the recursive option is enabled by default. Also, it will exclude directories of version control systems (like .svn, CVS, .bzr, .git) and nicely formats hits.
E.g., "ack-grep foo" will search all (relevant) files in the current directory for "foo". And if the current directory is under source control, it will be much faster than using "grep -R foo .", since it excludes the control directories. (Ye
I haven't tinkered with its options or man page, although I'm using it since quite some time now, since the defaults are so good already and it provides a great out-of-box experience and performance boost.
The man page states when to use the "normal" grep:
WHEN TO USE GREP
ack-grep trumps grep as an everyday tool 99% of the time, but don’t throw grep away, because there are times you’ll still need it.
E.g., searching through huge files looking for regexes that can be expressed with grep syntax should be quicker with grep.
Additionally, "grep" appears to be still more useful when chaining commands, e.g. to find all references of "css" in the file list of "ack-grep" ("dpkg -L ack-grep | xargs grep css"). When using ack-grep here, it will also recursively search in all listed directories (as in "for i in $(dpkg -L ack-grep); do test -d $i && echo $i; done").
On Debian/Ubuntu, ack-grep is only a "sudo apt-get install ack-grep" away.. 
(The ack homepage has some convincing Testimonials, too)
5 comments
If you're looking for something similar that's a bit more pythonic and has a bit simpler command line options, try out grin: http://pypi.python.org/pypi/grinMy favorite feature is searching in specific file types: grin -I*.js connect. I know ack can do this, but I could never remember the --type flags for it. The other cool thing is that the output of grin is colored and highlights where in the line the pattern shows up.
ack highlights hits, too 
Cool, thanks. 
Ack-grep saved my life several times. I'm using it a lot now on iPhone development:http://bcaccinolo.wordpress.com/2010/09/28/killer-tool-to-develop-on-iphone-ack-grep/
I'm really puzzled why people prefer 'ack' over 'grep'. It doesn't seem to provide anything that grep doesn't. Of the listed 'reasons to prefer ack' on it's homepage, almost all of them are false or misleading or undesirable.grep will also recurse into directories ('-r'), and it will highlight hits ('--color'). It will skip source control directories ('--exclude-dir=\.git')
ack is advertised to be faster, but it is only faster because it skips searching a bunch of files. If you configure grep to skip source control, as above, and skip binary files ('-I'), then ack is actually slower than grep.
It's true that grep needs configuring to make it behave the way you want. So instead of installing 'ack', create an executable on your path to select the default options you want grep to use. Mine looks like:
$ 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 grep has been fine for me ever since.
The whole 'ack' project is a massive waste of time - throwing away decades of bugfixes, optimisations, and a community of knowledge, for no reason at all.
Comment feed for this post
![[FSF Associate Member]](/media/users/daniel/icons/fsfmem80x15.png){kind=icon}
