From owner-freebsd-hackers Wed Jul 11 11:52:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from www.kozubik.com (www.kozubik.com [166.90.8.185]) by hub.freebsd.org (Postfix) with ESMTP id EAEC137B401 for ; Wed, 11 Jul 2001 11:52:18 -0700 (PDT) (envelope-from john@kozubik.com) Received: from localhost (john@localhost) by www.kozubik.com (8.11.0/8.11.0) with ESMTP id f6BIkv757826; Wed, 11 Jul 2001 11:47:01 -0700 (PDT) (envelope-from john@kozubik.com) Date: Wed, 11 Jul 2001 11:46:57 -0700 (PDT) From: John Kozubik To: Leo Bicknell Cc: freebsd-hackers@FreeBSD.ORG, joelh@gnu.org Subject: Re: PR bin/7265 - ln In-Reply-To: <20010711115929.G63273@ussenterprise.ufp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think this sounds reasonable. If I may, I would suggest two small changes: "/sys: Symbolic Link destination src/sys does not exist" I feel that the actual words "symbolic link" are more appropriate than "SymLink", but more importantly, as we are striving for clarity in the error, the error can designate where the link attempted to incorrectly send the user. ----- John Kozubik - john@kozubik.com - http://www.kozubik.com On Wed, 11 Jul 2001, Leo Bicknell wrote: > > I'm going to dig up and old can of worms here, but I think I have > something new to offer that might fix it. This is in reference to > pr bin/7265, which can be found at: > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin%2F7265 > > >From the how to repeat section, probably all you need to know: > > # cd /usr > # ln -s src/sys /sys > # cd /sys > /sys: No such file or directory. > > (Emit the anguished wails of a tired sysadmin who thinks he's just > lost his kernel source. Repeating this last step is optional.) > > There was a lot of talk about adding flags to ln to fix this problem > to warn when the destination of a link doesn't exist and the like. > Rightfully so, many worried that adding flags would cause issues > (eg with POSIX options later) or that making ln emit messages in this > case might break shell scripts. I think these are all valid points > to one degree or another. > > But then it hit me, the problem isn't with ln. My origional discussion > is in the pr, but here's an abbreviated version. There is no error > in linking to a non-existing (at the time of link) file/directory. The > ln should not produce an error, and warnings are, in general, frowned > upon. However, there is very much an error from cd, and error that > is quite poorly reported. > > cd gets this partically right, if you try to cd to an actual file, it > produces a different error message: > > > touch file > > cd file > file: Not a directory. > > Quite clear. > > So, it would appear that the error "No such file or directory" really > means one of two things (that I've come up with so far, can we think > of more cases): > > "No such directory." > "Symlink destination does not exist." > > Let's consider my hypothetical patched cd (which means patched shells, > because it's a builtin): > > # cd /usr > # ln -s src/sys /sys > # cd /sys > /sys: Symlink destination does not exist. > > I think our sysadmin would not be wailing, or at least not so much in > that this error points you right where to look to either verify your > files are still there, or verify the link is wrong. > > Since there is no change to ln, I don't think anyone can object that > we're going to break scripts using ln. :-) The change to cd is only > in the text of the error message, which is made more specific. I > suppose someone could argue that a script uses that error message, > but I highly doubt it as the script should be using the return value > from cd, which would be unchanged. I also think it's hard to argue > that error messages that better pinpoint the problem are a bad thing. > > The biggest drawback to this solution is that it will require shells > to be changed, since as I mentioned before cd is a builtin. I still > think that's cleaner than polluting ln, and is also a superior fix > to the problem. > > Consider the can of worms open, who wants to bite? :-) > > -- > Leo Bicknell - bicknell@ufp.org > Systems Engineer - Internetworking Engineer - CCIE 3440 > Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message