🚀 go-pugleaf

In article <8903300354.AA14076@paris.Berkeley.EDU>, mcgrath%paris.Berkeley.EDU@GINGER.BERKELEY.EDU (Roland McGrath) writes:
> If foo is a symlink to a directory, `ls foo' should
> behave as if it were an actual directory; i.e., it should
> list the contents of the directory, rather than `foo@' (under -F).

The behaviour as you describe it is correct in the sense that all
versions of 'ls' I have used to date behave the same way (most notably
SunOS and other (?) BSD derivatives.  This does not mean that the
behaviour is not annoying....

The rationale may be that symbolic links are sort of like files themselves,
even if the name they contain points to a directory.


-- 
Greg Onufer .. University of the Pacific .. Focus Semiconductor
.. greg@cheers.uucp .. cheers!greg@lll-winken.llnl.gov .. 209-957-3963

In article <226@cheers.UUCP> exodus@cheers.UUCP (Greg Onufer) writes:
   The behaviour as you describe it is correct in the sense that all
   versions of 'ls' I have used to date behave the same way (most notably
   SunOS and other (?) BSD derivatives.  This does not mean that the
   behaviour is not annoying....

On the contrary, the reverse behavior is more annoying.  On the NeXT
machine, "ls /etc" tells you the uninteresting fact that /etc is a
symbolic link.  If I want to know about the link instead of its
referent I'd say "ls -l".  Actually, "ls -l /etc" isn't that useful
either.  I want to know about the contents of directories more often
than I want to know about the link.  Reverse the sense of the -L flag
for directories?  Probably a bad idea...

(Aside: "ls -F" should give links-to-directories a unique character
like ">", as 4.3 csh file completion does.)
--
Felix Lee	flee@shire.cs.psu.edu	*!psuvax1!shire!flee