Date: Wed, 11 Jul 2001 11:59:29 -0400 From: Leo Bicknell <bicknell@ufp.org> To: freebsd-hackers@freebsd.org Cc: joelh@gnu.org Subject: PR bin/7265 - ln Message-ID: <20010711115929.G63273@ussenterprise.ufp.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010711115929.G63273>