ack 2.0 has been released

[petdance]

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.

[tobyink]

For the last week or so I've been experimenting by setting a shell alias "grep" to point to ack 2.0. And so far the results have been good; or at least, I've not been annoyed enough to switch back.

My .ackrc contains:

--no-recurse

... so I get a grep-like non-recursive behaviour by default; and if I need recursion I just supply the -r option on the command line (just like I did with grep).

The other grep options I frequently use (-h/-H, -v, -i and -c) all Just Work™.

[petdance]

I've been experimenting by setting a shell alias "grep" to point to ack 2.0.

I suggest that you not do that. ack and grep are different tools. ack is not a replacement for grep. If you need to use grep, then use grep. If you need to use ack, then use ack.

[tobyink]

That's precisely why I set up the alias. For years, when I've needed to use something like ack, I've typed "grep" (muscle memory). The alias ensures that now, when I need to use ack, I get ack.

It's not like I've deleted /bin/grep and installed a symlink to ack; other users, shell scripts, etc, can still use the real grep.

[Anonymous Monk]

Fantastic, how can I call it from within my program?

Do you support something like the following?

my $iterator = App::Ack->fandango(qw[ -in dir1 dir2/dir3 --match ^the.
+start.ends.now$ ]);
while(my $result = $iterator->() ){
##    my( $file, $lineno, $line ) = $result->finoli;
##    my( $file, $lineno, $line ) = $result->fileNumberLine;
    my $file = $result->file;
    while( my( $lineno, $line ) = $result->next ){
       print "$lineno: $line\n";
    }
}

Or how about ack()?

my @finolis = ack( qw[ --perl --match \bVERSION\b\s*=(.*?)$ ] );
for my $finoli ( @finolis ){
   my( $file, $nolis ) = @$finoli;
   for my $noli ( @$nolis ){
      my( $number, $line ) = @$noli;
   }
}

Or --no-filename?  my @lines = ack( qw[ -h --perl --match sub\s+\w+ ]);

Or matches?  my @matches = ack( qw[ -o -h --perl --match sub\s+\K(\w+) ]);

Or  my @files = ack( qw[ -l --perl ], $dir1, $dir2, $dir3 );

Hmm, ??  my @files = ackfiles(qw[ --perl ], $dir1, $dir2 );
??  my @matches = ackmatches(qw[ --perl --match sub\s+\K(\w+) ]);
??  my @lines = acklines( qw[ --perl --match sub\s+\w+ ]);
??  ... = ackiterator(qw[ -in dir1 dir2/dir3 --match ^start.ends$ ]);

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)

Thanks for listening :)

[petdance]

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?

[Anonymous Monk]

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

that's the killer feature ack has over grep, is simple/easy filetype/mimetype ... recognition with --perl --cpp ...

Sure, I could cobble something together using MIME::Type/mmagic... and file::find,
or I could shell-out to ack , which i've done , but then switched to file::find::Rule (shell is bleh)

Have you seen File::Find seems grossly inefficient for performing simple file tasks??

ack does a good job on the cli, the interface is compact , I know it already, no need for File::Find::Rule->oopy->verbosity or all find2perl reams-of-machine-generated-stuff or different-interfac

compact interface for commandline? why not compact interface for commandline for our programs?

Is it too obvious? Too useful?

[MidLifeXis]

Sounds excellent! I am looking forward to learning more about this at the next Milwaukee.pm meeting.

[parv]

Thanks for the first & fourth points listed in change list.

[Anonymous Monk]

Hmm, globbing support for win32 appears to have been dropped

[Anonymous Monk]

still gone in 2.08

[petdance]

What do you mean by "globbing support"? There has never been globbing support in ack. Any globbing is the responsibility of the shell.