Date: Thu, 4 Jan 2001 10:12:29 -0600 (CST) From: Mike Meyer <mwm@mired.org> To: groggy@iname.com Cc: questions@freebsd.org Subject: Re: ln bug? Message-ID: <14932.41197.304664.500594@guru.mired.org> In-Reply-To: <82011091@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
groggy@iname.com types: > > > > 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. 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?14932.41197.304664.500594>