nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OT: ack - written in perl, "better than grep"

tanguyr

http://betterthangrep.com/

I'm on Solaris with only POSIX grep by default, this think is waay better, **smoking** fast, and works just fine with iw-perl. Check it out, you won't be disappointed.

/t

Find more posts tagged with

Comments

Adam Stoller

http://betterthangrep.com/

I'm on Solaris with only POSIX grep by default, this think is waay better, **smoking** fast, and works just fine with iw-perl. Check it out, you won't be disappointed.

/t

In what context do you make this statement?
Are you doing benchmarks of Perl code that both calls out to the POSIX grep and uses the built-in grep - in order to get a sense of overall performace - or are you just impresses with grep functionality that you didn't know existed?

ISCBorisB

I'm on Solaris with only POSIX grep by default

'grep' is a built-in Perl function

tanguyr

In what context do you make this statement?
Are you doing benchmarks of Perl code that both calls out to the POSIX grep and uses the built-in grep - in order to get a sense of overall performace - or are you just impresses with grep functionality that you didn't know existed?

No, i'm just using it from the command line for now (i just found this thing), but, to search for text in my DCRs, i tried this:


find . -name "*.xml" -exec fgrep -l "mysearchtext" {} \;

vs this:


ack --xml "mysearchtext"

and the second one if four times faster (approx. 5500 DCRs in the category i'm looking through). As for the functionality thing, i'm used to gnu grep at home (linux) but at work i'm stuck with POSIX grep, and i keep missing all those extra goodies like context, only matching, etc.., which this thing has.

I haven't looked into integrating this into any scripts ... yet

/t

nipper

No, i'm just using it from the command line for now (i just found this thing), but, to search for text in my DCRs, i tried this:
find . -name "*.xml" -exec fgrep -l "mysearchtext" {} \;
vs this:
ack --xml "mysearchtext"
and the second one if four times faster (approx. 5500 DCRs in the category i'm looking through). As for the functionality thing, i'm used to gnu grep at home (linux) but at work i'm stuck with POSIX grep, and i keep missing all those extra goodies like context, only matching, etc.., which this thing has.

I haven't looked into integrating this into any scripts ... yet

/t

That is because you are using find and executing a new fgrep on each item. The overhead of starting a new process/environment is huge.

Depending on what grep you have, there is a recursive option, though as Bo pointed out, a perl copy of grep is still faster than native.

tanguyr

Depending on what grep you have, there is a recursive option, though as Bo pointed out, a perl copy of grep is still faster than native.

Yup, the -R/-r/--recursive option to gnu grep... which POSIX grep doesn't have. I'm not a perl dev, but i have heard that perl's File::Find (or whatever it's called) is faster than Unix's find.

What i like about this tool is that i don't need to learn any perl to use it and it replaces a bunch of convoluted find/exec/grep/xargs command lines i've had to cobble together to get stuff done on Solaris. Even better, it works the same way on linux (at home), so any time i invest in learning it there pays off directly at work (which certainly wasn't the case with sed and awk for example)

/t