Find 165 designed with a human user and modern networking in mind. The Unix file finder program, find, wasn’t designed to work with humans, but with cpio—a Unix backup utility program. Find couldn’t anticipate networks or enhancements to the file system such as symbolic links even after exten- sive modifications, it still doesn’t work well with either. As a result, despite its importance to humans who’ve misplaced their files, find doesn’t work reliably or predictably. The authors of Unix tried to keep find up to date with the rest of Unix, but it is a hard task. Today’s find has special flags for NFS file systems, sym- bolic links, executing programs, conditionally executing programs if the user types “y,” and even directly archiving the found files in cpio or cpio-c format. Sun Microsystems modified find so that a background daemon builds a database of every file in the entire Unix file system which, for some strange reason, the find command will search if you type “find file- name” without any other arguments. (Talk about a security violation!) Despite all of these hacks, find still doesn’t work properly. For example, the csh follows symbolic links, but find doesn’t: csh was written at Berkeley (where symbolic links were implemented), but find dates back to the days of AT&T, pre-symlink. At times, the culture clash between East and West produces mass confusion. Date: Thu, 28 Jun 1990 18:14 EDT From: pgs@crl.dec.com Subject: more things to hate about Unix To: UNIX-HATERS This is one of my favorites. I’m in some directory, and I want to search another directory for files, using find. I do: po pwd /ath/u1/pgs po find ~halstead -name "*.trace" -print po The files aren’t there. But now: po cd ~halstead po find . -name "*.trace" -print ./learnX/fib-3.trace ./learnX/p20xp20.trace ./learnX/fib-3i.trace ./learnX/fib-5.trace ./learnX/p10xp10.trace

166 csh, pipes, and find po Hey, now the files are there! Just have to remember to cd to random directories in order to get find to find things in them. What a crock of Unix. Poor Halstead must have the entry for his home directory in /etc/passwd pointing off to some symlink that points to his real directory, so some com- mands work for him and some don’t. Why not modify find to make it follow symlinks? Because then any sym- link that pointed to a directory higher up the tree would throw find into an endless loop. It would take careful forethought and real programming to design a system that didn’t scan endlessly over the same directory time after time. The simple, Unix, copout solution is just not to follow symlinks, and force the users to deal with the result. As networked systems become more and more complicated, these prob- lems are becoming harder and harder: Date: Wed, 2 Jan 1991 16:14:27 PST From: Ken Harrenstien klh@nisc.sri.com Subject: Why find doesn’t find anything To: UNIX-HATERS I just figured out why the “find” program isn’t working for me any- more. Even though the syntax is rather clumsy and gross, I have relied on it for a long time to avoid spending hours fruitlessly wandering up and down byzantine directory hierarchies in search of the source for a program that I know exists somewhere (a different place on each machine, of course). It turns out that in this brave new world of NFS and symbolic links, “find” is becoming worthless. The so-called file system we have here is a grand spaghetti pile combining several different fileservers with lots and lots of symbolic links hither and thither, none of which the program bothers to follow up on. There isn’t even a switch to request this… the net effect is that enormous chunks of the search space are silently excluded. I finally realized this when my request to search a fairly sizeable directory turned up nothing (not entirely surprising, but it did nothing too fast) and investigation finally revealed that the directory was a symbolic link to some other place.