Comment by spudlyo | Hacker News Reader

Comment by spudlyo | Hacker News Reader

I knew before I even clicked on this article, that something inside was going to cause me nerd rage; it's almost always the case when I read these Baby's first UNIX type articles. I thought this one might be different when I saw Andy's formidable neck beard, and for the most part it was decent but then I saw it.

..plus Ack is 4 or 5 times faster than grep.

Ack is implemented in Perl, which has a full featured regex engine, but is not generally known for being super fast. It's going up against GNU grep, which is a highly tuned regex engine, which is very fast. The ack guys make the argument that ack is faster because it doesn't search stuff you, the developer, don't care about, which in my estimation is horseshit. Try it yourself, I threw a regex at my email spool from the 90s which is about 128M. I made sure it was in disk cache first and then did:

    chunky:~$ time egrep -c -i '(d|m|j)ingle' RMAIL
    23

    real    0m3.129s
    user    0m3.075s
    sys     0m0.051s

    chunky:~$ time ack -c -i '(d|m|j)ingle' RMAIL
    RMAIL:23

    real    0m26.208s
    user    0m26.060s
    sys     0m0.121s

Yeah, I don't like it when people spout speed comparisons without backing it up either.

A lot of people do want/need PCRE, which ack relieves the pain point for.

GNU grep also supports PCRE.

    chunky:~$ otool -L /usr/bin/grep | grep pcre; grep --help | grep perl
      /usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
      -P, --perl-regexp         PATTERN is a Perl regular expression

Many users choose ack over grep for the same reason they choose htop over top, tmux over screen, zsh over bash, and postgres over mysql -- the perception that one is significantly better than the other. This advocacy often comes from folks whose use and understanding of either tool is superficial at best.

I often see ack recommended by word of mouth but unfortunately I feel it's between programmers that don't understand the Unix command-line enough to instruct grep, find, xargs, etc., sufficiently accurately to do what they intend and ack has the allure of doing the right thing, though often slowly, as you say. GNU grep's -I option to ignore binary files for example, or -boa to search binary files.

Once the standard commands are learnt then by all means use ack if you understand the trade-offs and can fall back to the normal way when on another system or when ack's insufficient.

How would you exclude the same kinds of files that ack does in grep without typing out the exclude patterns?

As described here ( http://blog.sanctum.geek.nz/default-grep-options/ ), you could use GREP_OPTIONS, but then you run into the problems here ( http://brainstorm.ubuntu.com/idea/24141/ ) -- scripts that use grep without clearing GREP_OPTIONS will fail.

Do you have an alias? Or another script that wraps grep?

    find . -type f -name \*.[ch] | grep -v \\.git | xargs grep something

Normally my directories aren't going to have .bzr, .git, .hg, and .svn in the same directory tree, but if they did it wouldn't be that much harder.

    alias nocrap="egrep -v \\.\(git\|bzr\|hg\|svn\)"
    find . -type f -name \*.[ch]| nocrap | xargs grep whatever

This is how I do it because I'm lazy. I suppose I could tell find to exclude directories so it wouldn't have to recurse into them, but the list of directories and files in my source tree is almost always in buffer cache anyway, so I never really worry about it.

You might want to consider using single quotes to protect your globs and regexps more rather than backslashes. \✳.[ch] will match the ./✳.c that may have been accidentally created by an earlier error, then find will only look for a file called precisely ✳.c and nothing else. '✳.[ch]' or \✳.\[ch] is what's meant.

(Edited to use ✳ to workaround unescapable mark-up.)

Good point, thanks!

My normal way of running grep is ~/bin/g.

    #! /bin/sh

    exec egrep --color "$@"

(Not a bash, my shell, alias because they're unavailable in many contexts.)

egrep is AKA grep -e. I don't use GREP_OPTIONS because it pollutes those that don't expect it, as you pointed out.

At the top of a particular source tree I may have a ./g that knows more about what's interesting.

    #! /bin/bash

    find \( -name .svn -o -name tags \) -prune -o -type f -exec egrep "$@" {} +

It checks -name before -type because the latter needs a stat(2).

For other things I do ad hoc queries using grep, find, xargs, etc.

htop over top, tmux over screen, zsh over bash, and postgres over mysql

That doesn't seem like a good comparison to me. I use htop over top because it has features that top doesn't have (the funky coloured ASCII graphs). I use tmux over screen because unicode seems to work without any effort on my part. I use bash because I have never looked at zsh in detail and don't care enough. I use postgres because I like its license better than mysql and its not controlled by any one company.

So its not at all about the perception that one is significantly better than the other, at least for me, its about specific features (license is a feature). Or in the case of zsh vs bash, where there are no specific features, I use bash because it seems to be the default on most distros.

I like ack because I like the output format better.

Reply on news.ycombinator.com