Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!think!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.unix.wizards
Subject: Re: Should "ls -R" traverse symlinks?
Keywords: symlink, find
Message-ID: <12377@bloom-beacon.MIT.EDU>
Date: 2 Jul 89 13:44:33 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 34

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