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.
Right. There's no need to write a whole new tool just to simplify invocation for common cases. For a guy who uses the command line "a LOT" he's not making good use of his shell.
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.
The -print0/xargs thing is to get around spaces in filenames or directories. I don't think spaces belong in source files (or directory trees containing source code) for a gazillion different reasons, but I still stumble across it every once in a great while. There are also platforms where system directories have spaces in them, so if you're scrounging through a deep subdirectory tree trying to find something, you may have to deal with the spaces thing. I've been bitten by it enough times that I just always do this rather than have to think about whether or not I might need to do it every time I use find.
Depending on what I'm looking for, I might select files with -type, or a -name glob, or whatever. I use '-type f' most commonly because the source code I deal with has a fair number of interesting things defined outside of files with the standard source/header extensions in their names.
There's usually a couple pipe stages after this filled with 'grep -v <stuff I don't care about>', or more greps to narrow down the result set. Sometimes this all goes in shell scripts or sometimes I just type it all out.
Alternatively, you may just install locate. It won't examine file contents, but it works in the common cases. It's also blazingly fast because it's indexed.
Its problem that you always have to update the index, which can be problematic in fast changing systems (and quite slow in some cases).
The greatest disadvantage is that you need root rights to update the index.
You can have arbitrary indices being created by arbitrary users. The database(s) that is(are) used by the locate command can be specified by command-line option or by an environment variable.
I looked into his python implementation, I thought he would just translate the parameters and call find, but he instead did go to implement the search algorithm.
Wouldn't that make it a bit slower than the original find?
File system traversal can be quite slow on traditional hard disk drive, it requires a lot of random disk access which has much higher latency than sequential access (think about the moving parts in the disk drive). So I guess that being written in Python is hardly the bottleneck if the disk reads have not been cached by the kernel.
The main difference is that, where `ffind foo` appears to be comparable to
, ff is closer to 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.