Find is a beautiful tool

`find` is beautiful, no discussion. Together with tools like xargs there's hardly anything you can't do with it.<p>Following is slightly off-topic but for searching inside files like<p><pre><code> find . -name "*.css" -exec grep -l "#content" {} \; </code></pre> try `ack` instead<p><pre><code> ack --css '#content' </code></pre> Above command will recursively search for '#content' in all css files under the current directory. It is faster than grep and does automatically exclude your hidden version control folders. No need to mess with `--exclude`. I really stopped using grep at all. ack can be found here: <a href="http://betterthangrep.com/" rel="nofollow">http://betterthangrep.com/</a>

I've struggled to understand 'find' for a while. It doesn't seem to fit *nix conventions in its syntax. For one, the path argument comes before any options or flags. Also, what is the point of the '-print' option? Pretty much every other utility prints results to stdout by default. This is expected and necessary for piping commands together.<p>I'm not arguing about the value of 'find' (indeed, this recent article well explains its usefulness: <a href="http://news.ycombinator.com/item?id=2698180" rel="nofollow">http://news.ycombinator.com/item?id=2698180</a>). I just fumble every time I try to use it because it seems to contravene conventions. I welcome any historical context or clarification if my expectations are in fact flawed.

I like to write complex find commands with find-cmd which is bundled with emacs (disclaimer: I wrote it):<p><pre><code> (find-cmd '(prune (name ".svn" ".git" ".CVS")) '(and (or (name "*.pl" "*.pm" "*.t") (mtime "+1")) (fstype "nfs" "ufs")))) </code></pre> becomes:<p><pre><code> "find '/home/phil/' \\( \\( -name '.svn' -or -name '.git' -or -name '.CVS' \\) -prune -or -true \\) \\( \\( \\( -name '*.pl' -or -name '*.pm' -or -name '*.t' \\) -or -mtime '+1' \\) -and \\( -fstype 'nfs' -or -fstype 'ufs' \\) \\)"</code></pre>

I think there comes a time for any unix user when you reach a break-even point - the added productivity of shell commands is greater than the head-scratching, googling and man page searches.<p>I remember finally 'getting it', and asking myself why anyone would want a computer where you don't have such tools.<p>My main gripe with the shell at this point is inconsistencies in syntax from one command to another, especially when it means different dialects of regex.

I wrote a similar post last year (<a href="http://rossduggan.ie/blog/codetry/extracting-information-from-a-lot-of-images-on-disk-using-find/" rel="nofollow">http://rossduggan.ie/blog/codetry/extracting-information-fro...</a>); it's one of those things you can't believe you worked without before. Easily one of the best tools in a developer's arsenal.

I use find all the time and have added a few handy functions to my fish shell so I can:<p>f '<i>.css' # regular recursive find for css files<p>f '</i>.css' '#content' # find and grep<p>fgu '*.css' '#content' # give a listing of unique css files containing '#content'<p>If anyone wants to take a peek, the f, fg, and fgu functions are on github (<a href="https://github.com/bartvandendriessche/fish-nuggets/tree/master/functions" rel="nofollow">https://github.com/bartvandendriessche/fish-nuggets/tree/mas...</a>).

I wrote an article on `find` performance a few years ago, may be useful to someone:<p><a href="http://scott.wiersdorf.org/blarney/071024a.html" rel="nofollow">http://scott.wiersdorf.org/blarney/071024a.html</a><p>tl;dr version:<p>find examines each entry in a directory hierarchy; if the entry (be it a regular file, symlink, directory, device, or whatever) matches the given criteria, it will be printed. If no criteria are given, it’s an automatic match (and will be printed).<p>find evaluates its expressions in the order you specify them; by carefully choosing the order of the expressions, you can shave tons of time off the cost of the search and get your wanted results quicker.<p>As is true with most programming endeavours, a little investment up front in crafting the expressions will yield better results later. If you’re only running a find operation once, maybe you don’t want to take too much time fussing over saving a few syscalls, but if you will be running find frequently (e.g., as part of a cron, or some other regular occurance), do your disk a favor and let find skip as much as possible.

It's not a beautiful tool, it's an over-large conglomeration of functionality that already exists in the shell. We don't even have it in Plan 9; here's how you can do some of the examples I'm seeing in comments here:<p>To just find a file:<p><pre><code> du -a . | grep filename </code></pre> To find every file containing the string "foo" (the awk is necessary to remove file sizes, you could combine du and awk in a shell function if desired):<p><pre><code> for (i in `{du -a . | awk '{ print $2 }'}) { grep 'foo' $i } </code></pre> Really, the for loop above takes care of a few of find's options. Why do you need both "-exec" and "-delete"? Exec is far more versatile, you can just exec "rm" on the files. Except that as I've shown above, it's already quite easy to execute a program for every file that matches some criteria, and you don't have to learn the dozens of options used in find--you just apply the shell programming knowledge you should (hopefully) already have.

I've never quite understood the point of find's -exec option. What's wrong with a pipe?

<i>If you’re on Windows, I would recommend installing Cygwin to bring the power of a real shell to your OS.</i><p>_yawns_<p>Can we please get past statements like these? They are _so 90's.<p>See Powershell: <a href="http://en.wikipedia.org/wiki/Windows_PowerShell" rel="nofollow">http://en.wikipedia.org/wiki/Windows_PowerShell</a>

zsh can be a shoein replacement for bash, and its globbing facilities makes 'find' almost obsolete for me. For example:<p><pre><code> find . -name "*.css" </code></pre> is:<p><pre><code> ls -d **/*.css </code></pre> in zsh. Other examples, all derived from the article:<p><pre><code> find . -type f -name "*.css" ==&#62; ls **/*.css(.) find . -name "*.css" -exec grep -l "#content" {} \; ==&#62; grep -l "#content" **/*.css find . -ctime -1 -type f ==&#62; ls **/*(.c-1) find . \! -path "*CVS*" -type f -name "*.css" ==&#62; ls **/*.css(.e{'echo $REPLY | grep -v "CVS"'}) </code></pre> More can be found in the "Glob Qualifiers" section of the zshexpn(1) man page.

another great switch is 'maxdepth':<p><pre><code> -maxdepth 1 will only search the current directory -maxdepth 2 will search 1 folder deep </code></pre> etc<p>I use this all the time

find -delete -name "<i>.pyc" is not the same as find -name "</i>.pyc" -delete<p>First one nukes everything including the git repo<p>Second does what I expect