karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (05/11/89)
Given a directory which contains entries like this ("ls -l"):
total 2
drwxr-xr-x 2 karl 24 May 11 08:41 real-directory
lrwxrwxrwx 1 karl 15 May 11 08:41 netnews -> /usr/spool/news
On a Sun3 running SunOS 3.5.1, "ls -R" does not traverse the "netnews"
symlink.
On a Pyramid running OSx 4.[04], "ls -R" *does* traverse the symlink.
Which is right?
--Karlguy@auspex.auspex.com (Guy Harris) (05/12/89)
>On a Sun3 running SunOS 3.5.1, "ls -R" does not traverse the "netnews" >symlink. > >On a Pyramid running OSx 4.[04], "ls -R" *does* traverse the symlink. > >Which is right? Assuming it's not a rhetorical question, the answer is probably "it depends". It depends on what you're using the "ls -R" for; there are probably cases where you want it to follow the link, and cases where you don't. I've probably run across both, or at least the moral equivalent of both, using "find"; given a choice of only one, I'd *probably* go for "don't follow", given that people have gotten rude surprises when symlinks *were* followed by things like the shell (e.g., "rm -f */*", only one of the first "*"s is a symlink to some directory that you *really* didn't want to ream out). "ls" isn't likely to be as rude as "rm", but still... (and, of course, you *could* be using the "ls" to generate a list of files to be monkeyed with somehow). So what you want, presumably, is a "follow/don't-follow" flag. The "-L" flag to "ls" is such a flag; I tried an example like yours on a SunOS 4.0 system, and "ls -R" didn't follow the link, but "ls -RL" did. Of course, "ls -RL" will follow *every* link it runs across.
flee@shire.cs.psu.edu (Felix Lee) (05/12/89)
No. Not unless "ls -R" detects cycles and guarantees termination.% If you really want to traverse links, "ls -RL" is almost adequate. % A normal "ls -R" can still loop, but this should be uncommon. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
fawcett@steven.COM (fawcett) (05/17/89)
In article <KARL.89May11084518@triceratops.cis.ohio-state.edu>, karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: > Given a directory which contains entries like this ("ls -l"): > > total 2 > drwxr-xr-x 2 karl 24 May 11 08:41 real-directory > lrwxrwxrwx 1 karl 15 May 11 08:41 netnews -> /usr/spool/news > > On a Sun3 running SunOS 3.5.1, "ls -R" does not traverse the "netnews" > symlink. > > On a Pyramid running OSx 4.[04], "ls -R" *does* traverse the symlink. > > Which is right? Just for fun, I wnet around the net to all of the different machines we have here (Sun, Tektronix, Dec 3100, and Intergraph) and looked at the man pages for ls. They ALL had the -L option described, which reads: -L If argument is a symbolic link, list the file or direc- tory the link references rather than the link itself. Now, I am not sure if this is standard, but it seems that is four out of four vendors have it here, it would be at least a de-facto standard. I looked in both my K&P and "The UNIX(tm) system users manual" by AT&T and saw no referance to a -L flag on ls. The AT&T book does list the -R flag, but does not indicate that if the directory is a link, that the link will be resolved. I know this isn't much help, but it looks like it was up to the vendors to put this in however they felt like, if they did at all. BTW, the AT&T book is dated 1986. John W. Fawcett ----- ----- ----- ----- ----- ------ Software Engineer / / / / / / / / / Sierra Geophysics, Inc . ----- / /--- /----- /----- /-----/ P.O. Box 3886 / / / / \ / \ / / Seattle, Wa. 98124 ----- ----- ----- / \ / \ / / Voice: (206) 822-5200 uucp: ..!uw-beaver!sumax!quick!ole!steven!fawcett
flint@gistdev.UUCP (05/23/89)
You didn't see anything in the AT&T Docs because SYSV doesn't support symbolic links at all, at least not until Release 4.0.
dg@lakart.UUCP (David Goodenough) (06/06/89)
flee@shire.cs.psu.edu (Felix Lee) sez: > No. Not unless "ls -R" detects cycles and guarantees termination. > If you really want to traverse links, "ls -RL" is almost adequate. Agreed > % A normal "ls -R" can still loop, but this should be uncommon. Forgive my ignorance, but I don't see how - not unless you do some real dirty mucking with a directory open as a file for write, and start messing with Inode numbers in directory slots - or am I missing something. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
scs@adam.pika.mit.edu (Steve Summit) (07/02/89)
One wart I'd like to see added to the clutter surrounding
symlinks is to base the decision to follow the symlink on whether
it was mentioned explicitly or found during a directory descent.
For instance, I'm always doing
find /usr/src ...
but the sources are often on another partition, with /usr/src
being a symlink pointing to them, so find (which doesn't normally
traverse symlinks) returns immediately, finding no files.
I can perhaps see the wisdom of not following a symlink found
during a recursive descent (avoiding loops and so on) but if I
say to look in /usr/src, I'd really like to search the sources,
even if they're pointed to by a symbolic link.
There's no doubt that symlinks are useful, but it's discouraging
how many propagating difficulties they introduce. When they were
first announced, I guessed that the number of programs that would
have to be modified to know about them would be quite small --
perhaps
ln (to add -s to create them in the first place)
tar (to preserve them)
stat (not even a standard chapter 1 command, unfortunately)
However, for good reasons or ill, it seems that nearly every
program that calls stat(2) now wants to special-case ST_IFLNK.
(And yes, this is a problem -- new kernel features ought to drop
in transparently, not requiring modification of large numbers of
user-mode programs.)
Steve Summit
scs@adam.pika.mit.edugwyn@smoke.BRL.MIL (Doug Gwyn) (07/07/89)
In article <12377@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >There's no doubt that symlinks are useful, but it's discouraging >how many propagating difficulties they introduce. ... >However, for good reasons or ill, it seems that nearly every >program that calls stat(2) now wants to special-case ST_IFLNK. Yes -- as a case in point, the BRL UNIX System V emulation for 4.nBSD initially always traversed symlinks, because System V at the time didn't have symlinks and the simplest emulation was to treat them transparently. As I found problems applying the System V utilities with that behavior to actual instances of symlinks on our systems, I gradually added more and more special-casing, or in some cases options, to the utilities, just as you indicated. It's one of the things that led me to conclude that symlinks weren't sufficiently elegant to include in the "ultimate" operating system (whatever that may be).
jonathan@comp.vuw.ac.nz (Jonathan) (07/22/89)
In article <558@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >flee@shire.cs.psu.edu (Felix Lee) sez: >> No. Not unless "ls -R" detects cycles and guarantees termination. >> If you really want to traverse links, "ls -RL" is almost adequate. > >Agreed These postings have completely lost the point of the original query, which was ``Should ls -R traverse symlinks on a *Pyramid*''? Pyramid's OSx is a dual-universe Un*x implemented using conditional symbolic links---symlinks that contain the names of two files, one each for the bsd and att universe. For instance, /bin is a csymlink to .ucbbin and .attbin, respectively. Since OSx's lstat(2) does not distinguish between ordinary symlinks and csymlinks (perhaps because Pyramid didn't want to break user code that happened to do an lstat on a c-symlink; perhaps because the implementation is a kludge), having OSx commands do different things for ordinary symlinks and conditional symlinks is well-nigh impossible. Pyramid have modified several OSx commands to grok conditional symbolic links. OSx's ls follows symlinks symlinks by default, *doesn't* follow them for ls -L. (This makes sense to me. Seeing the conditional symlinks is generally not what people or shell scripts want to do. The incompatibility of ls itself is rather annoying, especially in an environment with other Unix implementations.) Since ls follows symlinks by default, it seems consistent and least surprising for ls -R to to traverse symlinks, which can lead to the problems already discussed. Perhaps an option meaning "follow conditional, but not ordinary, symlinks" is what's wanted. Despite Pyramid's inelegant implementation, there is an interesting issue here: What should the behaviour of ls (+ system calls, other commands) be when the mapping from pathnames to files is a relation rather than a function? Are there any other systems that use conditional symbolic links? Do Sequent systems deal with this issue, and if so, how? Are there any heterogenous distributed systems that use conditional symbolic links? Discussion, anyone?? -- ----------------------------------------------------------------------------- sane mailers: jonathan@comp.vuw.ac.nz | NZ Industrial democracy: UUCP path: ...!uunet!vuwcomp!jonathan | One factory, one vote!