A similar post popped up a couple weeks ago, and one comment suggested https://github.com/ggreer/the_silver_searcher. I was using ack at the time, but I'm really liking ag as I've found to be quite a bit faster. The one thing I wish it had was being able to restrict searches by file type.

Yep. I switched from grep to ack then to ag. ag is incredibly fast.

You can limit the files it searches with -G <pattern>

for those who are frequently searching paths with a large number of files stored on an SSD or ramdisk/tmpfs, the bottleneck is very much the CPU time.

in these cases ag is noticeably faster (orders of magnitude, in some cases), especially if you're just searching a literal and not with a regex pattern.

the author has done some really cool performance hacks, and written some great blog posts[1] along the way.

[1]: http://geoff.greer.fm/2012/09/03/profiling-ag-writing-my-own...

I was a bit surprised by a simple test I just ran on a Linux 3.10 tree:

    time rgrep aes . > /dev/null 
    real 0m0.900s
    user 0m0.548s
    sys  0m0.340s

    # Somewhat similar output to ag:
    time rgrep -n --color aes . > /dev/null 
    real 0m1.177s
    user 0m0.876s
    sys  0m0.288s

    time ag aes > /dev/null 
    real 0m1.147s
    user 0m1.040s
    sys  0m0.548s

    # Using fixed strings in grep, limiting us to searching c-files
    time rgrep -n --color -F --include='*.c' aes . > /dev/null 
    real 0m0.936s
    user 0m0.720s
    sys  0m0.208s

    time ag -G \.c aes > /dev/null 
    real 0m1.130s
    user 0m1.140s
    sys  0m0.428s

This is on an encrypted volume sitting on top of a low end SSD, all runs with hot chache. The times here are from ag in Debian -- I tried a build from upstream git -- but with essentially the same time.

I guess ag might make sense under OS X -- but there doesn't appear to be any (speed) advantages under GNU/Linux.

nice, thanks for sharing.

I was actually contrasting it to ack in my speed claims. I don't expect that it'd be that much faster than GNU grep in most situations.

Thanks, I was looking for this as well. ag --help could probably be reworked a little bit; --include makes more sense than -G / --file-search-regex in my opinion.

Thanks. Didn't read the manpage too carefully. Still not quite as easy as with ack, but probably good enough for me.

Not quite what you want, but you can restrict the search to filenames matching certain pattern with the -G option. For example, ag <pattern> -G \.c will only search on C files.

I second this. My friend kept suggesting I switch from Greg to ack. I searched for it and found ag and fell in love with it's speed. That same friend has now switched too.

Indeed, I've also been using ack for a while, and switched to ag. Much faster.

I'm pretty accustomed to using find | xargs grep.

This lets me completely tailor the file I search using find's filters (e.g., only search files with a .py extension, and skip .svn/ directory). E.g. assuming I'm in my project's root directory:

  find . -name .svn -prune -o -name '*.py' -print | xargs grep -Hi 'string or RE I am looking for'

I used to do the same, but this accomplishes the same thing and is much more concise

ag -i -G '\.py$' 'string or RE I am looking for'

Or you can do:

  ack --python PATTERN [DIRECTORY]

I'm pretty happy with `find|xargs grep` myself. Of course, I have an alias that hides the arcane incantation away under a single `frep`, but underneath it uses those tried and tested unix tools. An alias is usually simpler to carry with me to new systems as well.

My alias is my .bash_history :).

I grant that these other tools are great, but I like using the standard utilities because, among other things, once you learn 'find' and 'xargs' you can piece together all kinds of other commands and you don't have to remember a tool-specific syntax (at least for the 'find' and 'xargs' parts).

You can do something like : ag -G ".txt$" hello

ag is indeed incredibly fast and extremely useful. It's replaced grep for me, any time I need to do a recursive search.

Yep. Came here to recommend ag. It's just fantastic.

If you use GIT, checkout also 'git grep' command.

It'd be cool to see these sorts of new search tools integrate into the git ecosystem. I wonder how much faster 'git ack' would be than just straight-up ack -- in other words, could ack benefit from any of git's working tree and delta-based optimizations / awareness?

Besides only searching the files in the working tree, and more easily searching previous revisions, there won't be any speed improvements. Even if a file is stored using deltas, you still need to fully reconstruct it (more processing).

For full-file queries, sure. But I could imagine asking temporal questions like "show me changes made in the last month that introduces API x", for example.

Yes, more people need to know about "git grep". Did you know you can do things like `git grep -e foo --and -e bar --and --not -e baz`? "git grep" is great.

Anyone know of a tool like ack/ag which also lets me search for a term in proximity to another?" For example, find <foo> within 5 lines of <bar>"

You could do this with grep or ack or ag:

  grep bar -A 5 -B 5 files... | grep foo

-A n prints n lines following the match (bar) and -B n prints n lines before the match.

-C x does the same as both -A x and -B x together

(A - after, B - before, C - context)

I guess you could setup Sphinx to index your code :) "If it's worth doing, it's worth overdoing!"

http://sphinxsearch.com/

If you don't want/have Perl installed or are just a Python aficionado - check out https://github.com/eliben/pss/ - the Python-based ack clone. It's also actively developed.

if you use vim and vundle

Bundle 'mileszs/ack.vim'

ack is the bomb.