RSS | Module Info | Add a review of ack

ack (1.80)

Lovely grep -r -alike tool. In daily use here too. I like the way that "ack foo | grep bar" reverts back to including filenames on each line to make it more usable, and also that it skips .svn dirs.

Ack FTW!

adam - 2008-07-03 06:32:00
Was this review helpful to you?  Yes No

ack (1.82)

This is a very well put together replacement for "grep -r" that works the way you always wished "grep -r" worked straight out of the box. The documentation describes how to tweak the configuration to make it even more what you want. This is becoming indispensable.

hanenkamp - 2008-04-14 09:31:01
Was this review helpful to you?  Yes No

ack (1.76)

Ack has become one of those utilities that I use so much that I've developed muscle memory for it, when logged into servers that don't have it installed I keep trying to use it and have to make a conscious effort to stop myself and type 'grep' instead of 'ack'...

Jason Kohles - 2007-12-27 05:44:15
Was this review helpful to you?  Yes No

ack (1.74)

I consider ack to be much more useful than grep because:
- Perl regular expressions
- Coloring of not only the search term, but the filename
- The ability to group (e.g., instead of:
myfile.txt: this what found
myfile.txt: this was also found
myfile.txt: this was also also found in the same file!
you get:
myfile.txt
this what found
this was also found
this was also also found in the same file!)

This is what I like to do when searching ebooks and such:
ack --color --group -i '\bsearchTerm\b' | less -R
# ^^ so so so beautiful and readable (because of the colors and unexcessive formatting)

Another point that makes ack so great is the ability to use --passthru to just color the output. Such an ingenius tool! While I haven't used --passthru to color output yet, I'll know I'll be using it soon. Perl regexp + logger coloring == 1337.

There might be issues with wanting to search only certain directories and files that match a regular expression. My solution would be to use find. Something like this (untested):
find -type f ! -regex '.*/bad_dir/.*' \( -name "*.cpp" -o -name "*.h" -o -name "*.crazy" \) -exec ack --text --color --group 'searchThis' '{}' \; | less -R

I do however felt that file extensions shouldn't have anything to do with what is searched, and so I feel like the option --text should be on by default. The --text option forces _all_ text files to be searched -- regardless of file name extension. Sometimes I do searches and I ask myself "why aren't these files matching when they should be (i.e., they _are_ text files)?" -- and then I'm like "ooohh, because I forgot --text" (i.e., their file extensions were not matched by 'ack' to be searchable by default -- e.g., .pdftxt).

So an alias ack='ack --text' in the .bashrc saves the day.

P.S.
I was surprised ack is not in a Debian package, but a `cpan App::Ack` installed the much appreciated tool. (I forgot to use dh-make-perl *shrugs*.)

Corey D. Hollaway - 2007-12-12 15:39:14
Was this review helpful to you?  Yes No

ack (1.66)

Using this tool since some times now, and it has really eased my life. Really a must-have for any developper.

Sébastien Aperghis-Tramoni - 2007-10-15 07:46:16
Was this review helpful to you?  Yes No

ack (1.58)

This is a great tool. It’s not going to replace grep anytime soon, but for the subset of grep tasks that developers commonly need, it’s extremely convenient.

However, I really, *really* miss the --exclude and --include options from grep. My projects often contain directories with large files containing code that aren’t actually code I’m writing, such as database dumps or compressed Javascript libraries, which clutter the results. It’s possible to kludge around the problem a lot of the time by using options such as --nojs and/or --nosql. But when I want to search the database schema files that *are* part of my own code, or I want to search in my own Javascript sources, then I’m left with some awkward `find -some -predicates -type f -print0 | xargs -r0 ack` construction – which is much worse than the grep equivalent.

So that’s my verdict: this is already a tool every developer should have. And if it had --exclude/--include, it would be *perfect*.

Thanks, Andy.

Aristotle Pagaltzis - 2007-02-27 16:40:42
Was this review helpful to you?  Yes No

ack (1.58)

This rocks. Just removed a bunch of awk/sed/find/grep alias in my *.rc files since this handles them all much more nicely. Huzzah.

Adrian Howard - 2007-02-27 02:21:28
Was this review helpful to you?  Yes No

ack (1.26)

I thought it was much better than "Cats". I will see it again and again.

David Alan Pisoni - 2006-09-05 10:50:04
Was this review helpful to you?  Yes No

ack (1.24)

As the other two reviewers pointed out, this is a great improvement on grep -r and is a huge timesaver. It's a small little tool, but it's extremely handy. It has been useful to me on a daily basis. Quick!

Jen Stander - 2006-08-16 12:39:41
Was this review helpful to you?  Yes No

ack (1.24)

This is an absolutely superb tool and, as Audrey comments, a vast improvement over `grep -r`, if only because its output doesn't hurt your eyes so much. Add to that the default ignoring of certain directories like 'blib' and you're in search heaven. Oh, and it's /fast/.

Install this module now!

Earle Martin - 2006-08-04 05:15:59
Was this review helpful to you?  Yes No

ack (1.24)

If you have ever used "grep -r", switch to ack now. Guaranteed instant gratification and countless hours of time saved!

Audrey Tang - 2006-07-16 19:54:41
Was this review helpful to you?  Yes No

Perl.org sites : bugs | dev | history | jobs | learn | lists | use © Copyright 2002-2008 The Perl Foundation Site Information and Contacts