Live data from Hacker News

ffind: a sane replacement for command line file search

wrongsideofmemphis.com

21–30 of 40 posts

Re: ffind: a sane replacement for command line file search

#21
post #3

Similarly, I have a little shell function loaded by .zshrc that covers 90% of my use cases: findit() { find . -name \* -exec grep -iH $1 {} \; }

Why not just run a recursive grep? That would save having to invoke grep on every single file found.

    findit() {
        grep -iHR $1 .
    }
Alternately, you could use the '+' variant of -exec in order to batch files together to be processed together.

Re: ffind: a sane replacement for command line file search

#22
post #21
post #3

Similarly, I have a little shell function loaded by .zshrc that covers 90% of my use cases: findit() { find . -name \* -exec grep -iH $1 {} \; }

Why not just run a recursive grep? That would save having to invoke grep on every single file found. findit() { grep -iHR $1 . } Alternately, you could use the '+' variant of -exec in order to batch files together to be processed together.

Cool, I wasn't aware of a -R flag in grep for some reason. I need to go back and re-read the man pages...

Re: ffind: a sane replacement for command line file search

#27
post #20

Yeah thats ok but holy cow, thanks for letting me find out about ack! ack is awesome!

If you like ack (and who doesn't???), you might like more or less `ag`: https://github.com/ggreer/the_silver_searcher

ag is great - so much faster than Ack.

Re: ffind: a sane replacement for command line file search

#28
Many of the commenters here have missed an essential line of ffind's description from the article, emphasis mine:

> find in this directory and all the subdirectories a file that contains some_text in its filename

This is NOT a find+grep/ack/ag -alike. It's used for rapid search on filenames, not file contents. Think of it as TextMate's Cmd-T for the command-line.

Re: ffind: a sane replacement for command line file search

#29
I wrote a similar tool to this in C, ff (https://github.com/silentbicycle/ff).

The main difference is that, where `ffind foo` appears to be comparable to

    find . -name "*foo*"
, ff is closer to

    find . -name ".*f.*o.*o.*"
In other words, you don't need an exact match, just the characters given in order. (This is inspired by Lisp-y toolchains where e.g. c-w-c-c would search and expand to call-with-current-continuation.)

There are some other features (e.g. '=' toggles literal match, it has smart handling for '/' and directory name grouping), but it's pretty straightforward to use. It also doesn't depend on python.

Post reply on HN