Date: Fri, 5 Jan 2001 08:38:12 -0600 (CST) From: Mike Meyer <mwm@mired.org> To: groggy@iname.com Cc: questions@freebsd.org Subject: Re: ln bug? Message-ID: <14933.56404.946443.58230@guru.mired.org> In-Reply-To: <200101051432.OAA20806@en26.groggy.anc.acsalaska.net> References: <200101051432.OAA20806@en26.groggy.anc.acsalaska.net>
next in thread | previous in thread | raw e-mail | index | archive | help
groggy@iname.com types: > thanks for the understanting. > > i does seem to hurt the overall efficiency to make > all programs that use ln to have to do their own > work in recognizing relative paths thought ... > alot of redundant checking throughout programs. Again, it's not ln, it's symbolic links. Only shell scripts should call ln; every other programming (which excludes the simple scripting languages like awk and sed) lets you access the symlink and link system calls directly. If it really bothers you, create a patch for ln that behaves the way you want, and send-pr it. ln isn't even 250 lines long. Oh yeah - make sure you don't break the behavior that lets you create symlinks to files that don't exist yet. <mike > ... but thanks. i appreciate you shairng your knowledge. > > > > > > > is this a bug in "ln"? > > > > > > > > > > > > if i am in a directory with a file xxx: > > > > > > > > > > > > ln -s xxx /tmp/xxx > > > > > > > > > > > > will create link /tmp/xxx, but it will point to itself in /tmp. > > > > > > ln is not pointing the link to to xxx in the current directory > > > > > > as specified/intended on the command line. doesn't seem right. > > > > > > > > > > No, that's right. When making symbolic links, the first argument is > > > > > the _string_ that the link points to. It is better to not think of > > > > > symbolic links pointing to a specific file. Rather, when a symbolic > > > > > link is processed as part of a path, the string value of the link is > > > > > substituted. > > > > > -- > > > > > Crist J. Clark cjclark@alum.mit.edu > > > > > > > > That is a neat explanation for something that can be quite difficult to explain! > > > > It might be worth pointing out to people getting their head around this > > > > for the first time that the "_string_" may not necessarily exist as a file, symbolic links > > > > can "point" to thin air. This is particularly irritating for > > > > bad typists... > > > > > > > > Cliff > > > > > > what makes "ln" so special? it's only function is to reference a file/dir > > > just like "cp" or "mv" or "rm" or any other utility operating on files. > > > ok - it's valid to point to nothing, but that doesn't make it logical > > > for it to be so incongruous with the operation of other utilities > > > with respect to treating a "string" as relative if it has no > > > leading slash ... > > > > It's not ln that's special, it's symbolic links. If you make a hard > > link (leave off the -s flag to ln), you get the behavior you're > > looking for. The reason for that is because a hard link, like mv or > > cp, references a file instead of a string. None of these commands know > > anything about relative file names. The open and link system calls > > turn strings into file references, which is how relative file names > > are dealt with. The symlink system call doesn't do that translation, > > because a symlink references a string instead of a file. > > > > > is this a POSIX standard of "ln" operation? i dunno ... the man page > > > states nothing about POSIX compatibility. is there a good reason > > > for not parallelling all other utilities that operate on files > > > with repect to recognizing relative pathnames as such? > > > > Actually, the current behavior *is* parallel. They all just pass > > strings to system calls where file names belong. Making ln do this > > would involve making ln recognize relative file names and do path > > translation for symlinks, which would make it not parallel the other > > utilities. > > > > <mike > > -- > > Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ > > Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. > -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14933.56404.946443.58230>