NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sys/sun/admin/8042

Internet Message Format | 1992-11-08 | 3.4 KB

Path: sparky!uunet!europa.asd.contel.com!emory!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!uwvax!astroatc!vidiot!ftms!brown
From: [e-mail] (Vidiot)
Newsgroups: comp.sys.sun.admin
Subject: Re: The case of the symbolic link traversal in 4.1.3
Message-ID: <[e-mail]>
Date: 6 Nov 92 17:57:46 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Vidiot)
Organization: Vidiot's Other Hangout
Lines: 74

In article <[e-mail]> [e-mail] (Duncan Sinclair) writes:
<In article <[e-mail]>, [e-mail] (Vidiot) writes:
<>
<> Over the weekend I upgraded a bunch of our SPARCstations to 4.1.3,
<> from 4.1.1 and 4.1.2.
<
<We've got all three, so I ran some tests...
<
<> In the past, if one did a 'ls -lga dir_name' and the dir_name was a symbolic
<> link, one could see the contents of the linked directory by appending / to
<> the end and doing ls again (ls -lga dir_name/).  Used to work great.  Now
<> 4.1.3 comes along and still only reports the link.
<
<I noticed this too, but thought it was because I had just started using
<the GNU version of ls, and that it GNU/POSIX brain-damage...
<
<Then when I saw this I ran a few tests, seems that it's not ls's fault,
<but the 4.1.3 kernel that does this.  It has changed the path semantics,
<so that "foo/" == "foo", rather than "foo/" == "foo/."
<
<This is against normal Berkeley semantics that says that a "" as the
<file name on any path is the same as ".".
<
<Apart from the unfortunate effect it has to "ls -l slink/", I think this
<is a positive change.
<
<One good reason why I like this new behaviour is that it allows
<me to type "rmdir foo/" (with help from my shell that automatically
<puts a slash on the end of directory names during completion),
<without it complaining "rmdir: foo/: Invalid argument"  (you cannot
<remove the directory "." in the directory "foo").

With zsh, it too puts the / at the end.  But, the 4.1.2 rm didn't give me
that error, it just said that it couldn't remove dir/.  It did remove all the
stuff in the directory though.

<I had an argument on comp.unix.programmer with some others as to how
<this should behave, when I was looking for this new behaviour.  So I
<now understand this area very well.
<
<> Why the Hell did Sun change ls so that it doesn't work the same
<> as it used to?  It came in very handy to be able to traverse the
<> link by adding a / to the path.
<
<Yup, I will miss this, I'd like this intelligence built into "ls",
<but adding a "/." isn't so hard.

I have been informed of the /. addition and will be using that.  I just glanced
through my 4.1.3 install manual and saw nothing there that mentions the /
being changed.  At least they could have put it in writing.

<> It doesn't matter if I use zsh or csh, it don't work.
<
<Or even which version of ls - 4.1.1,4.1.2,4.1.3, or even GNU.
<
<GNU's rmdir has this (new) behaviour hacked into it, perhaps the
<GNU ls could have the old behaviour hacked in also.
<
<> How do I get the old method back???????
<
<Get used to it....  This is probably the S5R4 way.

:-(

<> (Yes, I'm pissed :-)
<
<In the UK this means you are blind drunk.  I assume you don't mean this...

Ya, I thought of that.  But you are right, I didn't mean it that way :-)
--
harvard\
  ucbvax!uwvax!astroatc!ftms!brown  or  uu2.psi.com!ftms!brown
rutgers/
INTERNET: [e-mail]  or  ftms![e-mail]