Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uakari!indri!aplcen!haven!adm!xadmx!rbj@dsys.ncsl.nist.gov
From: rbj@dsys.ncsl.nist.gov (Root Boy Jim)
Newsgroups: comp.unix.questions
Subject: Question about ``find`` commnad
Message-ID: <20335@adm.BRL.MIL>
Date: 24 Jul 89 18:43:09 GMT
Sender: news@adm.BRL.MIL
Lines: 79

? From: David Elliott <dce@solbourne.com>

? In article <20285@adm.BRL.MIL> rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes:
? >Except that in every other part of the galaxy, they are *not* followed.
? >
? >I have nothing against nifty vendor extensions. There are many holes
? >in the utilities. But don't break existing interfaces without thinking!
? >
? >What's next? A `-h' option to `rm' that tells it to only follow hard
? >links, following symbolic links by default?
? >
? >Perhaps Tektronix should just stick to making oscilloscopes.

? Sometimes you can really piss me off, Jim.

I'd apologize, except that sometimes that's what it takes to get a response.

? In this case, changing find the way we did was considered to be the
? right thing to do.  ls, a much more widely used utility than find,
? followed symlinks, and in general, symlinks to directories were
? considered to be just like directories.

In general, symlinks are *completely different beasts*. Try typing
`rm -rf *' in a directory full of symbolic links to other directorys and
files. No problem, as symbolic links are not followed.

? Berkeley chose to be inconsistent.  My management chose to be consistent,
? in a time when there were no standards.

Berkeley chose correctly, they just didn't document their choices. They
presented symbolic links as a nearly compatible substitute for hard links,
but never told anyone about their subtleties. I can imagine they were
hammered out on a utility by utility basis. The documentation really
needs a paper entitled "Perils and Pitfalls of Symbolic Links", discussing
what choices were made and why.

BTW, when in doubt RTFS. Or ask Berkeley. You may have convinced them
to add `-follow' if you had sent them a diff and a good reason.

? We could have gone either
? way, and we chose to change find.

This is one of those `nifty vendor extensions' I mentioned earlier.
Find does need such an option. But you implemented it backwards.
You changed the default behavior. Dangerously.

? After all, it can be quite irritating
? to a user to tell a coworker to use 'find ~xyz ...' and have it work
? differently just because of symlinks.

It could also be really irritating if the `...' part happenned to
contain `-exec rm {} ";"'. Suppose I had a script that depended on
symbolic links not being followed? And suppose I ran it under Utek?

? I wouldn't make the same decision now, but now I'm not forced to do
? things I feel are ill-advised.

Congratulations on your new-found freedom. But you actually seem to be
agreeing with me here: `Yes, I new it was technically wrong, but I was
told to do it, and I couldn't convince them otherwise.'

? If you want to flame someone about breaking existing code, flame AT&T,
? who seem to enjoy doing this every time they release a new version of
? the os.

Hey, the people at AT&T think `cd ..' should do `cd $pwd:h'.
Need I say more?

? I'm proud of the work I did at Tektronix.  Hell, if Tek had gotten
? the SVR5.4 contract instead of Sun (and Tek was in the running for a
? while), AT&T would have made this change already.

If AT&T wants any clout with Berkeley devotees, they need Sun.

? David Elliott		dce@Solbourne.COM
? 			...!{boulder,nbires,sun}!stan!dce

	Root Boy Jim
	Have GNU, Will Travel.