tikku@imposter.samsung.com (Sanjay Tikku) (07/12/89)
The ``find`` command on our system does not follow the symbolic links which is also what the manual says. I thought that there was a ``-follow`` option to make it explicitly follow the symbolic links. Our version of find command does not support that option though. Does anyone know if BSD (or any version derived from it) has any option to make it follow the symbolic links. Any help on this subject would be helpful. thanx sanjay ================================+============================================= Sanjay Tikku | Voice: 508-685-7200ext.123 Sr. Software Engineer | FAX: 508-685-4940 SAMSUNG Software America, Inc. | Internet: tikku@samsung.com
dce@Solbourne.COM (David Elliott) (07/12/89)
In article <2087@ginosko.samsung.com> tikku@imposter.samsung.com (Sanjay Tikku) writes: >The ``find`` command on our system does not follow the symbolic links which >is also what the manual says. I thought that there was a ``-follow`` >option to make it explicitly follow the symbolic links. Our version of find >command does not support that option though. Does anyone know if BSD >(or any version derived from it) has any option to make it follow the >symbolic links. Any help on this subject would be helpful. The Tektronix UTek version of find (ca. 1985) had a -follow option. I seem to remember that -follow had an argument to it, but I can't remember what it's purpose would have been (maybe for following symlinks only when they are on the same filesystem?). There are two problems with the following of symlinks. Sometimes, you just don't want to, so you need to be able to turn it off, and sometimes you only want to follow them if they are on the same filesystem. I definitely remember that both find and ls -R followed symlinks, and saved a table of device/inode/hostid (for UTek's DFS) info for every directory entered to prevent symlink loops. -- David Elliott dce@Solbourne.COM ...!{boulder,nbires,sun}!stan!dce
jeff@quark.WV.TEK.COM (Jeff Beadles) (07/13/89)
>In article <2087@ginosko.samsung.com> tikku@imposter.samsung.com (Sanjay Tikku) writes: >The ``find`` command on our system does not follow the symbolic links which >is also what the manual says. I thought that there was a ``-follow`` >option to make it explicitly follow the symbolic links. Our version of find >command does not support that option though. Does anyone know if BSD >(or any version derived from it) has any option to make it follow the >symbolic links. Any help on this subject would be helpful. In article <1588@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes: >The Tektronix UTek version of find (ca. 1985) had a -follow option. >I seem to remember that -follow had an argument to it, but I can't >remember what it's purpose would have been (maybe for following >symlinks only when they are on the same filesystem?). An excerpt from the Utek find(1) man page... -follow type Always true. This option determines whether symbolic links to directories will be followed; by default, symbolic links to directories are followed. The option h type means that symbolic links to directories are not to be followed (in other words, follow only ``hard'' links). The last paragraph pretty well sums it up. I just looked at the rlog for find.c, and noticed that David installed the modification himself on 4/26/85. -Jeff -- Jeff Beadles Utek Sustaining Engineering, Tektronix Inc. jeff@quark.WV.TEK.COM
guy@auspex.auspex.com (Guy Harris) (07/15/89)
>Does anyone know if BSD (or any version derived from it) has any option to >make it follow the symbolic links. BSD doesn't. S5R4 (which is arguably derived from, among other sources, BSD :-)) will, I think, have a "-follow" option to do that.
nrg@nsscb.UUCP (Narotham Reddy) (07/18/89)
Dear Mr. Sanjay: Could you please give me the path name for shakti!betaal. uunet is no longer processing any requests for shakti. My messages came back. Thanks Narotham Reddy
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (07/19/89)
? From: Jeff Beadles <jeff@quark.wv.tek.com> ? An excerpt from the Utek find(1) man page... ? -follow type ? Always true. This option determines whether ? symbolic links to directories will be followed; ? by default, symbolic links to directories are ? followed. ? The option h type means that symbolic links to ? directories are not to be followed (in other ? words, follow only ``hard'' links). ? The last paragraph pretty well sums it up. I just looked at the rlog for ? find.c, and noticed that David installed the modification himself on 4/26/85. 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. ? -Jeff ? Jeff Beadles Utek Sustaining Engineering, Tektronix Inc. ? jeff@quark.WV.TEK.COM Root Boy Jim Have GNU, Will Travel.
dce@Solbourne.COM (David Elliott) (07/19/89)
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
rbj@dsys.ncsl.nist.gov (Root Boy Jim) (07/25/89)
? 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.snoopy@sopwith.UUCP (Snoopy) (08/05/89)
In article <20335@adm.BRL.MIL> rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes: |? >I have nothing against nifty vendor extensions. There are many holes |? >in the utilities. But don't break existing interfaces without thinking! |? > |? >Perhaps Tektronix should just stick to making oscilloscopes. This means *so* much coming from someone who wants to fundimentally limit root. (BTW, my Tektronix oscilloscope is in the shop for repair. :-( ) | Suppose I had a script that depended on | symbolic links not being followed? And suppose I ran it under Utek? Depending on symlinks being followed or not without testing is rather dangerous. (sad but true) Let us not forget the great pwd war. (Which was never really resolved as I recall.) | If AT&T wants any clout with Berkeley devotees, they need Sun. No, if AT&T wants any clout with Berkeley devotees, they need Berkeley. Sun != Berkeley. Perhaps you mean clout with BJ devotees? _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________| "But we're only up to the fourth inning."