34 ms·

The `find` command is not a very good example of Unix philosophy. http://doc.cat-v.org/unix/find-history http://doc.cat-v.org/unix/find-history provides an inte

by Jach 14y ago

The `find` command is not a very good example of Unix philosophy. http://doc.cat-v.org/unix/find-history http://doc.cat-v.org/unix/find-history provides an interesting snippet of its history, indicating that `find` and some other friends weren't designed by the research group of AT&T behind Unix. > ... take a moment to consider how utterly anachronistic both of the above solutions come across to non-believers in 2012 While this as the author admits isn't what he wants to talk about, I want to talk about it for a moment. Apart from `find` which is indeed archaic (few people seem to use its many built in features and pipe to simpler programs instead--e.g. preferring to pipe to xargs instead of using -exec), I'm struggling to find what's so old-fashioned about the grep example and what a modern, 2012 design should look like. Is it the '-v'? You can type '--invert-match' instead. Is the problem old-fashioned? I don't think so, I still occasionally pipe the results of find through grep -v and then on to something else. Is piping old-fashioned? Again, what's the 2012 version of these things? While I don't really like comparing programming languages to spoken languages (much like comparing OS kernels to popcorn kernels), I always liked this quote since I read it: "Linux supports the notion of a command line or a shell for the same reason that only children read books with only pictures in them. Language, be it English or something else, is the only tool flexible enough to accomplish a sufficiently broad range of tasks." -- Bill Garrett As for the "meat" of this post, well, we'll see how Light Table turns out. I'm not particularly excited about it but plenty of HNers are.

babarock 14y ago
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 http://mywiki.wooledge.org/ParsingLs).
- bcoates 14y ago
  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.
  - snogglethorpe 14y ago
    > 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.]
- Jach 14y ago
  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 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.)

by Jach 14y ago

babarock 14y ago

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 http://mywiki.wooledge.org/ParsingLs).

bcoates 14y ago
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.
- snogglethorpe 14y ago
  > 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.]
Jach 14y ago
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 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.)