Ack 2.0 has been released | Hacker News Reader

Ack 2.0 has been released

perlbuzz.com

214 pointspetdance44 comments

Anyone have a sense of how the new Ack 2.0 compares to The Silver Searcher[1] (aka Ag)? I've been using TSS for some time now and it's been completely awesome in both performance and functionality compared to Ack v1.

[1] https://github.com/ggreer/the_silver_searcher

I had never heard of The Silver Searcher. Thanks! A test search of a huge codebase (Firefox) took 38 seconds with ack, but only 17 with ag! After my page cache had been warmed up, ack then took 10 seconds and ag only took 3. That said, I am using ack 1.96, not ack 2.0.

  $ brew uninstall ack

It's OK to have two similar tools in your toolbox. When you need the --output option, for example, you use ack. When you want crazy speed, you use ag.

You don't have to choose one over the other. That's why I changed the name from "betterthangrep.com" to "beyondgrep.com". There's no need to have a ranking of "I use this over that."

Ah, you Perl guys and your "there's more than one way to do it". :-) Disclaimer: I'm a Perl guy and I agree.

Also, take a look at http://beyondgrep.com/more-tools/. There are a dozen other tools on there as well that you might well like as much as ack and ag.

An abundance of tools is good.

I've contributed to ag and followed it quite closely. That being said, I still have ack on all my systems because sometimes, being able to just do:

ack --python search-term is REALLY useful.

Turning things around, I often have SQL dumps around, so ack --no-sql is a real lifesaver in my Rails (i.e ruby, coffee, less, shell and whatnot) projects.

Though I've switched to ag, I still miss Ack's selection and deselection flags. Those are much sweeter than ag's -g and -G and it looks like they've improved further

As mentioned above, there's no need to have 'one search tool to rule them all.' You don't uninstall grep from your system when installing ag or ack.

> You don't uninstall grep

Beautiful. Thank you. I am stealing that for when I discuss this in other places.

It would be interesting to see benchmarks on this. I know TSS was faster before, and this release didn't seem to highlight any performance improvements.

Chances are that if there are any performance changes, it might even be a decrease in speed because of having to find .ackrc files. We haven't gone profiling 2.0 yet, but that's near the top of our list.

That's pretty much what I figured. If we wait a bit, I wouldn't be surprised to see a writeup from Geoff, the author of Ag. His blog posts when he started development on it were really interesting.

http://geoff.greer.fm/2011/12/27/the-silver-searcher-better-...

When it comes to improving Ag's speed, there's not much more to write about. I've used every dirty trick I know: mmap()ed I/O, threads, Boyer-Moore-Horspool strstr(), PCRE-JIT, etc. Now when I profile, Ag spends the majority of its time reading files off disk. On most systems, this is true even if the files have been cached in memory by the OS. The limiting factor is memory bandwidth.

Anyways, I don't really have the time for long analysis posts these days. I'm busy working on something that captures value in addition to creating it. :)

No mention of mmap in the ack release notes, so I'd imagine ag is still much faster.

sounds great - thanks! I hadn't heard of this before

ack has been an indispensable tool in my workflow for a few years now. I use it several times a day to search code bases... most of the time, not even taking advantage of regexes or all of its many abilities. Just a basic keyword search is usually enough; the output looks great.

The feature I've wanted the most is the local project-specific .ackrc ability. I have some projects where I need to be able to ignore specific files/dirs; I think this feature will address that need.

The silver searcher (Ag)[1] ignores files from .gitignore/.hgignore by default, so I find that this sort of project-specific configuration isn't generally needed. There are various editor plugins for Ag, e.g. Ag.vim[2] based on mileszs' excellent Ack.vim[3].

[1] https://github.com/ggreer/the_silver_searcher [2] https://github.com/epmatsw/ag.vim [3] https://github.com/mileszs/ack.vim

I usually just open up sublime on a codebase to do some quick searches, you can jump straight to the file and see the results in context.

Editor integrations fail badly with big codebases though. I don't use sublime text, but I can't imagine getting it to index, say, the entire kernel (or the /frameworks subtree of an Android build, etc...) faster than a recursive grep will return.

That said, I don't use ack. I've tried it a few times and it looks great and works well, but honestly this particular task turns out not to be one where I demand polish and features. Really, all I want is grep.

me too, i've tried ack several times but i'm not stuck to it because i've always been able to find anything i was searching for with, tataaa : simple grep and locate.

I use Sublime as my editor as well. Sublime's search functionality is pretty good too, and I can't there's anything bad about it, for my typical use cases... but I've become very used to reaching for ack, and I love the highlighting it uses. On the other hand Sublime does support double click to open on file names in search results.

Ack is wonderful example of tool use evolution. Before ack, I used grep to find stuff, but each use would frequently require additional options to exclude certain types of files, then coupled with a pipe to filter other stuff, etc, etc. After ack, everything is much simpler; just specify what you want. It has replaced most of my grep invocations. Honestly, if you work on the command line and use grep, you owe it to yourself to try ack. You (probably) won't look back.

Vim users, don't forget the essential ack.vim: http://www.vim.org/scripts/script.php?script_id=2572

Vim users, don't forget the included vimgrep. It greps your file. But the nice thing is, it puts the results in the quickfix window (where your compiler errors go, for example).

I keep a project log file in restructured text. My entry headers look like this:

  2013.03.17 Sunday, Set up base box
  ==================================

When you filter that file with rst2html, your output file can have a table of contents, but not your source file where you probably spend more time.

Use vimgrep to find all your headers:

  :vimgrep /^20[0-9][0-9]/gj %

Nothing happens, but the result is in the quickfix window.

  :copen

And now you have a second window with entries like the following:

  log.rst|1559 col 1| 2013.03.17 Sunday, Set up base box
  log.rst|1624 col 1| 2013.03.14 Thursday, configured widgets

In the quickfix window, enter on any line and it brings you back to the main window, at that location.

  :help vimgrep
  :help quickfix
  :help copen
  :help cc
  :help cn

Ack is a nice tool. I wrote a blog post about how to use it for ClojureScript within Emacs: http://inclojurewetrust.blogspot.de/2013/01/searching-in-clo...

Excellent. I've added it to the to-do list of articles to put on beyondgrep.com

https://github.com/petdance/beyondgrep/issues/12

We have a really big C++ codebase at work and I find codesearch[1] to be the best way to search through the code, although the UX is terrible compared to Ack/Ag. Another problem is that it's written in go; so hard to get builds for the AIX PPC machines. Faster than everything though -- running a complex regex against 2-3 million SLOC and getting an answer within a second is certainly worth something.

[1]: http://code.google.com/p/codesearch/

There's also cscope, which is ancient as the hills but still quite handy for navigating a codebase you're not completely familiar with.

Sadly this change broke every script I had which followed the old instructions for putting ack on a box:

    curl http://betterthangrep.com/ack-standalone > ~/bin/ack && chmod 0755 !#:3

Now gives a Nginx 302 text/html page. Yes, yes, I should have done curl -L, but those are the instructions they had pasted on the box.

In addition just changing the hostname

    curl http://beyondgrep.com/ack-standalone

just gives a 404.

I put in a redirect from http://betterthangrep.com/ack-standalone to the new location, but it's temporary. I never intended for anyone to use that command line as ad hoc API, nor did I realize that people were scripting against it. :-/

So, sorry I broke it, and, I can't promise that URLs are going to stay where they are unless I explicitly say that I am promising that.

Sweet. I'm a complete ack convert - `ack 'some str' --no-haml` (which, in rails project roots, will ignore specific build folders because of my .ackrc file) is just so much easier and more readable than the grep equivalent, it's hard to go back.

I couldn't do my job without ack. We have a code base with millions of lines of C/C++ and tons of PHP. I use ack every day to find code and files. I've been looking forward to 2.0 for a long time. Will try to help melt his server right now :)

I stopped using ack because it opens the same files several times (strace it to see for yourself - I've seen version 1.94 open the same file 17 times) and has problematic performance on our a little higher latency setup (Xen + FC storage). ag does everything I need and has no such issues...

I haven't used either one, but from reading the descriptions it sounds like ag has fewer features, for examples it doesn't have the --output option to tailor how results of matches are presented. On the other hand, it sounds like it should be faster.

Can someone explain how Ack is better than "git grep"? Assuming, of course, you use git to manage your code.

I find "git grep" as fast as Ack and very flexible.

Depends on what your needs are. Do you want the coloring and grouping? Do you want Perl regular expressions? Do you want to only search source code? Do you want to be able to specify specific filetypes, like "ack foo --perl" or "ack foo --nohtml"?

git grep is neither superset nor subset of ack. Each tool has its place.

There is a large world beyond source code. Surely you've done some system administration or looked in logs?

I'd suggest that for most cases that are not source code that you stick with grep.

I'd suggest that for most of my cases that are not source code that I'll stick with ack.

If you prefer Python and don't want to have Perl around just for the sake of 'ack', check out 'pss' - a similar tool written in pure Python: https://bitbucket.org/eliben/pss

[sorry for the plug, but it's definitely relevant to the discussion]

Is it common these days not to have perl installed? I assumed it was still standard on UNIX systems.

I count 308 perl scripts in my /usr/bin.

Actually my initial motivation for developing pss was Windows. I had to use Windows at work at the time, and installing Perl just for the sake of ack was pain. ack also needs an additional module from CPAN (for console coloring), so double pain.

Python, OTOH, is always one of the first I install on every machine that doesn't have it :) pss requires no installation, no additional modules, just Python.

Aside from embedded/routers and Windows machines, it's few and far between. At the very least you're going to have something ancient like Perl 5.6 or 5.8 installed.

Reply on news.ycombinator.com