Do you have an actual use case for these? Or are you just imagining things that might possibly potentially be cool in the future maybe?
Um, what? That was it, that was my actual use case, use ack in a program for the same reason I'd use ack from the commandline , to get a list of files, or get a list of lines, or get a list of files and lines
only the iterator portion inspired by File::Find::Rule/Iterator::Files iteration interfaces is a might-as-well-implement-it-if-you-re-implementing-it-thought-of-it-now
The most important thing ack does that I can't do as trivially /easily myself already is all the filetype stuff
sure it's easy to give find( qr/\.(pm|pl|pod|t)$/i ) for perl , i know perl, but what about --ruby? and others ...
that's the killer feature ack has over grep, is simple/easy filetype/mimetype ... recognition with --perl --cpp ...
Sure, I could cobble something together using MIME::Type/mmagic... and file::find,
or I could shell-out to ack , which i've done , but then switched to file::find::Rule (shell is bleh)
Have you seen File::Find seems grossly inefficient for performing simple file tasks??
ack does a good job on the cli, the interface is compact , I know it already, no need for File::Find::Rule->oopy->verbosity or all find2perl reams-of-machine-generated-stuff or different-interfac
compact interface for commandline? why not compact interface for commandline for our programs?
Is it too obvious? Too useful?
| 