Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!husc6!psuvax1!flee From: flee@shire.cs.psu.edu (Felix Lee) Newsgroups: gnu.utils.bug Subject: Re: GNU ls bug Message-ID: Date: 2 Apr 89 22:11:18 GMT References: <8903300354.AA14076@paris.Berkeley.EDU> <226@cheers.UUCP> Sender: news@psuvax1.cs.psu.edu Distribution: gnu Organization: Penn State University Computer Science Lines: 18 In-reply-to: exodus@cheers.UUCP's message of 30 Mar 89 19:52:22 GMT 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