petdance

I'm going to be making a new chart that is more about features than command flags. I'll include the licensing information. Thanks. https://github.com/beyondgrep/website/issues/80

There's a link to the issue tracker right there at the top of the page.

ack will always be slower than ripgrep, but it shouldn't be as slow as it is in burntsushi's tests. In his tests, he's showing run times where ack takes 25x as long to run as ripgrep, and ack shouldn't be NEARLY that slow.

We think that there's something weird about his Perl installation that is making it so slow, but we haven't been able to figure it out.

Here's the ticket: https://github.com/beyondgrep/ack3/issues/42

If you have any insight, we'd love to have it. We've been stumped, as you'll see if you read through the issue history.

I added smartcase in ack because I used it constantly in vim. I don't normally want to have to remember if the function I'm searching for is "format_ISBN" or "format_isbn", for example. Some languages (PHP) aren't always case-sensitive, so you need to search both. I'd rather use a "-I" in the few cases where I don't want case-sensitive, than having to remember to add "-i" in the 99% of the cases where I don't.

Author here. I don't know about "The Secret" other than it being an Oprah thing, what, ten years ago?

Abundance vs. scarcity has nothing to do with “Believe and you shall receive... somehow”.

Scarcity thinking means that you fear giving people credit, and letting others have success. You fear that praising others makes you seem weak. You think that if someone uses a different open source project than yours, that you or your project suffers. You might not even be aware of the thinking. You might just feel it reflexively.

Abundance thinking says that there is more than enough praise to go around. It says that your success doesn't hurt me in mine (unless in some tangible way it does). It says that you can use ag and I can use ack and Susan can use ripgrep and it's all good.

In this specific case, abundance says that I, as the creator of ack, don't need to own the "market". In fact, the creation of other tools only helps ack. It gives the ack team ideas for things we can implement in ack. Who am I to think that I'm the only one with good ideas?

It gives our users a wider choice of tools. I put my work out there publicly to help people. Why would I not want them to have a variety to choose from?

That's abundance vs. scarcity.

ack has a configuration file, and it's extremely flexible, including the ability to check shebang lines. If you have a shell script without an extension, it's the only way to know what language it is.

It's going to be two pages ultimately. If you're comparing features, you don't care about the how.

Right now we're keeping all the data in a JSON file that we massage into a chart. Massaging it into a true feature comparison chart, along with a rosetta stone, should be a simple matter of programming. Same thing with the GNU/POSIX/BSD rosetta stone we're working on.

https://github.com/beyondgrep/website/blob/dev/comparison.js...

Good to know. I've been considering dropping ACK_OPTIONS, and this just might put me over the edge.

I've updated the phrasing so it says "Re-enable case-sensitive search over case-insensitve or smart-case search".

No, the chart doesn't compare speed. Lord knows there have been many comparisons of the speeds of grep-alikes, but nobody has written up a comparison of features.

For me, raw speed is not as important as a rich feature set to support my code spelunking.

ack does the "limit by a certain filetype", and it also lets you define your own file types or extend existing ones. ag does not.

ack does not look in .gitignore files at all.

Author here. Yes, that's really what it is. I need to make one that's actually feature comparison more than phrasebook.

We're also working on a GNU grep vs. POSIX grep vs. BSD grep phrasebook.

What kind of OS are you running that Perl isn't installed already?

> He's made the world a better place for many

Most importantly, that doesn't mean he's going to make Google a better place, or that his skills will be usable at Google.

It's probably more correct to say "Nobody complained in a public forum for 6 years."

There's having fun, and then there's violating the Principle of Least Astonishment. https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

> they like Perl and ack and occasionally use some of that fancy superpower. I, on the other hand, lack that experience

One of the things I'm working on right now is a cookbook that will ship with ack 3, currently about thisclose from going to beta. I want to show examples of the magic powers and see how powerful it can be. Your comment reinforces in my mind that it's an important thing to have.

> I’m very glad that ack existed; it led the way with better tools, and I used it heavily for some years. Thanks for making it!

You're very welcome. I'm continually pleased to see what's come out after it. A search tool arms race is a good thing.

You're very welcome. I'm glad it's made things easier. git grep, ag, rg, whatever: Just use whatever makes you happiest.

It's interesting how git grep makes the ack feature of "ignore your VCS dirs" not so important any more. I wonder how the grep-alike tool world would look if git weren't so dominant, and/or git didn't include its own grep.

Thanks for the clarifications. I was under the impression that Rust required a lot of tough infrastructure.

I'm glad to see that ripgrep lets you define your own types. That ripgrep does it with globbing vs. the ways that ack allows is just another of the differences between the tools that people have to decide about.

What do you mean by a "invested in a Perl workflow"? Do you mean "comfortable with Perl regexes"?

Other reasons that you may want to use ack:

* You want to define your own filetypes

* You want to define your own output using Perl regexes

* You need the portability of an uncompiled tool in a single source file that you can drop into your ~/bin when you can't install or compile anything on the box.

* You don't want to have to deal with a Rust runtime.

> they automatically skip binary and VCS-ignored files

If it does less work, and takes less time, then isn't that faster?

Creator of ack here.

The three biggest reasons to use grepalikes is not necessarily the time to execute the search, but

1) The reduced amount of typing. It's much faster to type "ack foo --ruby" than it is to type "find . -name '* .rb' | xargs grep foo"

2) Better filetype matching, because ack and ag check things beyond just file extensions. ack's --ruby flag checks for *.rb and Rakefile and "ruby" appearing in the shebang line, for example.

3) More features that grep doesn't include, like better highlighting and grouping, or full Perl regular expressions (in ack) and a ton of other features.

Here's a command line to find all the header files in your C source. It takes advantage of the ability to use Perl's regular expressions to specify output:

ack --cc '#include <(.+?)>' -H --output='$1' | sort -u

Here's an article I wrote a while ago on comparing the features of ack and ag. https://blog.newrelic.com/2015/01/28/grep-ack-ag/

Even though I created ack, I don't care which tool you use, so long as it suits your needs and makes you happy, but if all you're using your grep/ack/ag for is "grep -R function_name ." then you're only scratching the surface of what the tools can do for you.

I have to switch back and forth between ack and grep all the time. Sometimes I use ack, sometimes I use grep. I wrote ack, but I've never stopped using grep, and ack has never been intended as a replacement for grep.

For most of the common ack flags, they are the same as grep. -i, -l, -v, -w, -A, -B, -C, etc. That was intentional, to minimize that whiplash.

One other suggestion is that you drop ack into your ~/bin directory that you sync between machines. It's a single Perl file, and that portability is a feature. As long as your machine has a Perl on it, you can use ack.

Don't worry. The most common switches are the same between ack and grep:

    -i, --ignore-case
    -v, --invert-match
    -w, --word-regexp
    -l, --files-with-matches
    -L, --files-without-matches
    -o
    -m, --max-count=NUM
    -H, --with-filename
    -h, --no-filename
    -c, --count
    -A NUM, --after-context=NUM
    -B NUM, --before-context=NUM
    -C [NUM], --context[=NUM]

> after all project/bin/foo (executable) might be a python or perl or whatever script -- not just a binary file.

That's one of the big features of ack that the find/grep combo can't replicate is checking the shebang of the file to detect type. In ack's case, Perl and shell programs are detected both by extension:

  --type-add=perl:ext:pl,pm,pod,t,psgi
  --type-add=shell:ext:sh,bash,csh,tcsh,ksh,zsh,fish

And by checking the shebang:

  --type-add=perl:firstlinematch:/^#!.*\bperl/
  --type-add=shell:firstlinematch:/^#!.*\b(?:ba|t?c|k|z|fi)?sh\b/

Run `ack --dump` to see a list of all the definitions.

They solve different problems. Ctags and cscope index a corpus of source code, usually tied into another tool, like Ctrl-] in vim. ack searches the files every time.

There's a list of other tools for search source code besides ack at http://beyondgrep.com/more-tools/, including other grepalikes and indexing tools like ctags and cscope.

I suggest that you need not limit yourself to only one tool for your code searching. Toolboxes FTW.

> I think it's important not to throw grep away

Exactly. There's no reason that you can't have grep AND ack AND ag in your toolbox to choose from.

ag is not "exactly like" ack. There are features that ack has that ag has chosen not to replicate. ack is also more portable.

That's not a knock on ag at all, and if ag fits your needs, then by all means use it.