Hacker News new | ask | show | jobs
by pydave 5068 days ago
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?

2 comments

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.

    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!