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.

Find 167 I don’t want to have to check out every directory in the tree I give to find—that should be find’s job, dammit. I don’t want to mung the system software every time misfeatures like this come up. I don’t want to waste my time fighting SUN or the entire universe of Unix weeniedom. I don’t want to use Unix. Hate, hate, hate, hate, hate, hate, hate. —Ken (feeling slightly better but still pissed) Writing a complicated shell script that actually does something with the files that are found produces strange results, a sad result of the shell’s method for passing arguments to commands. Date: Sat, 12 Dec 92 01:15:52 PST From: Jamie Zawinski jwz@lucid.com Subject: Q: what’s the opposite of ‘find?’ A: ‘lose.’ To: UNIX-HATERS I wanted to find all .el files in a directory tree that didn’t have a corresponding .elc file. That should be easy. I tried to use find. What was I thinking. First I tried: % find . -name ’*.el’ -exec ’test -f {}c’ find: incomplete statement Oh yeah, I remember, it wants a semicolon. % find . -name ’*.el’ -exec ’test -f {}c’ \ find: Can’t execute test -f {}c: No such file or directory Oh, great. It’s not tokenizing that command like most other things do. % find . -name ’*.el’ -exec test -f {}c \ Well, that wasn’t doing anything… % find . -name ’*.el’ -exec echo test -f {}c \ test -f c test -f c test -f c test -f c