Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!stan!dce
From: dce@Solbourne.COM (David Elliott)
Newsgroups: comp.unix.questions
Subject: Re: Question about ``find`` commnad
Message-ID: <1681@marvin.Solbourne.COM>
Date: 19 Jul 89 14:15:03 GMT
References: <20285@adm.BRL.MIL>
Reply-To: dce@Solbourne.com (David Elliott)
Organization: Solbourne Computer Inc., Longmont, Colorado
Lines: 36

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.

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.

Berkeley chose to be inconsistent.  My management chose to be consistent,
in a time when there were no standards.  We could have gone either
way, and we chose to change find.  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.

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

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.  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.

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