11–20 of 51 posts
You mean the engine that lets you write pathological regular expressions[1] and accidentally ReDoS[2] yourself? To be fair, it's fine if you understand how the engine works well enough to avoid these cases. But how many people can actually say this?
>The primary virtue of these commands is that they use the Perl regular expression engine. You mean the engine that lets you write pathological regular expressions[1] and accidentally ReDoS[2] yourself? To be fair, it's fine if you understand how the engine works well enough to avoid these cases. But how many people can actually say this? 1. http://swtch.com/~rsc/regexp/regexp1.html 2. http://en.wikipedia.org/wiki/Re…
if you want the silver needle, the unsophisticated, greppy way of doing this would be: $ grep needle haystack|grep silver Why not simply $ grep "silver needle" haystack?
When I use double grep in real life, I often tend to do so on a relatively large haystack, where I don't necessarily know what the second search term will be. In that situation, I'll usually do the first grep, look through its output, and add on the second grep once I see something in the first grep's output that I want to narrow the results down to.
Of course, instead of adding on a second grep, I could modify the original regex (and sometimes I do); but if the original regex is complicated, then modifying it is error prone. And, anyway, using a shell abbreviation, it's very easy to type " G " and have that expand to " | grep " to simply add on another grep, without touching the first regex.
A second, quite common use case for a double grep is when I want the second search term to match whether it's before or after the first term. There's probably some convoluted way to get the same effect using a single regex, but it probably won't be nearly as easy or intuitive as a double grep.
When I need to do these sort of tasks, I do them in a scripting language with some combination of split() and regex instead of using command line tools. But, I'm just doing that because it's what I know.
Would I end up saving a significant amount of time if I learned to use grep instead?
Well, let's apply that same criteria to searching for two terms:
> grep needle haystack|grep silver
> ack '(?=silver).*needle' haystack
Look at that one character shorter than ack and just 10 times easier.
grep wins, by a knockout.
Things that do sell ack, for me:
ack css_class --sass # search .sass and .scss
ack some_method --no-flash # ignore .as and .mxml
# ignore compiled css in every Rails project on
# my system (as long as I `ack` from the root)
--ignore-dir=public/stylesheets/compiled
path/to/file.ext
123: some text matching
234: more text matching
path/to/other/file.ext
480: a match
path/to/file.ext:123: a match
path/to/other/file.ext:567: another match
path/to/that/file/you/didnt/know/you_had.ext:32: yet another match
Why is: ack -C5 'scope(?!.*lambda)' app/models Better than: grep -C5 scope app/models | grep -v lambda ?
$ grep needle haystack|grep silver
This sucks.
In most cases grep is going to be faster that ack. If you are searching large files this can make quite a difference.
Is it worth learning grep or ack or a similar tool? When I need to do these sort of tasks, I do them in a scripting language with some combination of split() and regex instead of using command line tools. But, I'm just doing that because it's what I know. Would I end up saving a significant amount of time if I learned to use grep instead?