Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re^3: ack 2.0 has been released (?wishlist?)

by Anonymous Monk
on Apr 29, 2013 at 16:14 UTC ( #1031253=note: print w/replies, xml ) Need Help??

in reply to Re^2: ack 2.0 has been released (?wishlist?)
in thread ack 2.0 has been released

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?

  • Comment on Re^3: ack 2.0 has been released (?wishlist?)

Replies are listed 'Best First'.
Re^4: ack 2.0 has been released (?wishlist?)
by petdance (Parson) on Apr 29, 2013 at 16:35 UTC

    You do realize that ack's filetype detection is A) nothing at all related to MIME::Type, and B) entirely based on user-created rules, right? ack ships with sensible defaults, but they're still user-defined rules.

    If it's File::Find that you are fighting with, then why not take a look at File::Next, which is the underlying file-finding engine that ack uses?

    When I asked about use cases, I should have been more clear: Have you actually written code where you shell out to ack to get filenames? Or had it give you search results? What did you do with the search results then?

    Is it too obvious? Too useful?

    I don't understand what you're asking here.

    If you'd really like to get some traction on some sort of ack API, please go create a ticket in the GitHub issue tracker at



      No thanks

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1031253]
[stevieb]: I finally got all of my tests to run against my App::RPi::EnvUI!! I am so pleased :) Now to add more tests, update the documentation, some code cleanup, put in production in my largest operation, and do a non-beta release

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2017-12-16 00:10 GMT
Find Nodes?
    Voting Booth?
    What programming language do you hate the most?

    Results (446 votes). Check out past polls.