Comment by babarock | Hacker News Reader

Comment by babarock | Hacker News Reader

Parent Full thread

I don't like the way `find` is being criticized, both in the article and in your comment. I won't go into pointless bickering on why it's a wonderful tool and "my stuff is better than yours". Let's keep using the tool we're each comfortable with. But do I really need to point out that, once you go through the initial learning curve, `find` is probably (one of the, if not) the most powerful tool in the Unix toolbox? If Unix's shell power comes from piping commands for streams to flow through, I find that in the vast majority of the cases `find` is the best way to initiate this stream.

And the reason is that it's reliable (unlike `ls`) and isn't wasteful (unlike the most-misused-tool-of-all `cat`). I don't understand why similarly newbie-unfriendly tools (like `sed` or `awk` for instance) never get as much heat as `find` does from people unfamiliar with it. Is it because the name implies that it should be a simple tool?

As for what's wrong with the `ls ... | grep -v ...`. It can break in so many ways like for instance, if a filename contains a newline character. If you think that never happens, you're making the same mistake me and a thousand of newcomers before me made once and never repeated again.

As a rule of thumb, never parse the output of ls (http://mywiki.wooledge.org/ParsingLs).

To quote myself, "...I still occasionally pipe the results of find through grep -v and then on to something else..." I agree find is greatly useful for the purpose of finding files (I don't know how Windows sysadmins could live without it) and learning its basics is important in one's mastery of the shell, but it's clearly "not like the others". It has useful options to control its behavior like outputting with null separation (something I wish `ls` had), following symbolic links, searching up to a maxdepth limit, and limiting the type to file or directory. And in the same way you can make justifications for the utility of other `find` features, but for nearly all of them and the ones I mentioned they have an irregular syntax. There are also things that obsolete `find`'s features like `xargs` that are simple to use and easy to understand and are useful in more contexts than `find`, even if using them has some performance hits. (And `locate` obsoletes `find` almost entirely because of performance when you need to search big swathes of your system.)

I think Ritchie sums up my feelings for `find` with "...we were somewhat put off by the syntax of their things. However, they were clearly quite useful..." `find` is useful, it's just not Unix-y. Does it still follow some of the Unix Philosophy in spirit? Maybe. I think there's also a chance that Unix Philosophy in its purest form is mostly dead in practice and has been for a while. Just look at the evolution of echo.c: https://gist.github.com/1091803

I'll readily agree that `ls .. | grep -v ..` can break, but I don't find anything archaic or non-Unix-y about it like I do with the `find` version. (Also every time someone uses `cat .. | grep ..`, a kitten dies. :( )

Finally, it's not the newbie-unfriendliness that `find` has, it's the irregularity and kitchen sink of features that aren't expressive and don't generalize well, as the other repliers elaborate on. In my experience `sed` and `awk` are more regular, more generally useful, and have less "intuition traps" than `find`. (As sort of a neatity aside from their surface-level expressiveness, both sed and awk are Turing-complete. I think it's interesting that my man page for sed(1) is 267 lines, my man page for gawk(1) is a hefty 1713 lines, and my man page for find(1) is also a hefty 1446 lines.)

I think awk gets a pass because it's a programming language with a handy syntax for running small scripts. Find is in an awkward position of being not quite that general but still very complicated.

The solution to filenames with newlines in them is one garbage-safe script involving 'rm' and a stern email to whoever created the file. Containing complexity instead of letting it leak into every single script is a good thing.

> I think awk gets a pass because it's a programming language with a handy syntax for running small scripts

Even more than that, awk's orientation towards filtering text lines made up of fields makes handling many little pipeline tasks amazingly simple. In combination with being a very nice little general-purpose programming language with good string support, awk is a no-brainer first stop for a lot of things.

[Other more recent programming languages generally have many more features, much better implementations etc, but nothing has improved or really even matched awk's smooth integration into the unix pipeline. Perl, for instance, although it's long tried to bill itself as a replacement for awk, and explicitly includes special features for such usage, can be significantly more awkward (er... :) for the sort of tiny little filters awk's really good at.]

Reply on news.ycombinator.com