ack 2.0 has been released. ack is a grep-like search tool that has been optimized for searching large heterogeneous trees of source code.

ack has been around since 2005. Since then it has become very popular and is packaged by all the major Linux distributions. It is cross-platform and pure Perl, so will run on Windows easily. See the "Why ack?" page for the top ten reasons, and dozens of testimonials.

ack 2.0 has many changes from 1.x, but here are four big differences and features that long-time ack 1.x users should be aware of.

By default all text files are searched, not just files with types that ack recognizes. If you prefer the old ack 1.x behavior of only searching files that ack recognizes, you can use the -k/--known-types option.

There is a much more flexible type identification system available. You can specify a file type based on extension (.rb for Ruby), filename (Rakefile is a Ruby file), first line matching a regex (Matching /#!.+ruby/ is a Ruby file) or regex match on the filename itself.

Greater support for ackrc files. You can have a system-wide ackrc at /etc/ackrc, a user-specific ackrc in ~/.ackrc, and ackrc files local to your projects.

The -x argument tells ack to read the list of files to search from stdin, much like xargs. This lets you do things like git ls | ack -x foo and ack will search every file in the git repository, and only those files that appear in the repository.

On the horizon, we see creating a framework that will let authors create ack plugins in Perl to allow flexibility. You might create a plugin that allows searching through zip files, or reading text from an Excel spreadsheet, or a web page.

ack has always thrived on numerous contributions from the ack community, but I especially want to single out Rob Hoelz for his work over the past year or two. If it were not for Rob, ack 2.0 might never have seen the light of day, and for that I am grateful.

A final note: In the past, ack's home page was betterthangrep.com. With the release of ack 2.0, I've changed to beyondgrep.com. "Beyond" feels less adversarial than "better than", and implies moving forward as well as upward. beyondgrep.com also includes a page of other tools that go beyond the capabilities of grep when searching source code.

For long time ack users, I hope you enjoy ack 2.0 and that it makes your programming life easier and more enjoyable. If you've never used ack, give it a try.

Hmm, i'm not sure about iterator :) but ackfiles/acklines/ackmatches seem like no-brainer-i-want-it feature, cause I've done that, ack ack ack some stuff, then write a File::Find::Rule loop to parse some files ... not exactly much harder to write, and ack() won't exactly shorten my effort that much, sure the file-type-matching logic will be the same, but I'm not sure if this would be useful

So, I've thought about it once or twice, might be nice, wouldn't take much effort to add-on this feature, but its not exactly a must-have, not sure it's really i-want-it, but I thought about wanting it on two occasions for about 5 seconds (honest)

Do you have an actual use case for these? Or are you just imagining things that might possibly potentially be cool in the future maybe?

Um, what? That was it, that was my actual use case, use ack in a program for the same reason I'd use ack from the commandline , to get a list of files, or get a list of lines, or get a list of files and lines

only the iterator portion inspired by File::Find::Rule/Iterator::Files iteration interfaces is a might-as-well-implement-it-if-you-re-implementing-it-thought-of-it-now

The most important thing ack does that I can't do as trivially /easily myself already is all the filetype stuff
sure it's easy to give find( qr/\.(pm|pl|pod|t)$/i ) for perl , i know perl, but what about --ruby? and others ...