Kazer Powa wrote: > On 06/18/2014 05:07 PM, Matt Burgess wrote: >> On 18/06/2014 16:05, Kazer Powa wrote: >>> Yep, I've read that, and I still believe it is wrong. It's not about >>> the ls command, it's about the path of the target. Of course the >>> command in the section 4.2 is right, as well as this one, but this >>> one's target path is wrong. >> Please don't top-post. >> >> The command is *not* wrong. The symlink's target is relative to its >> source, not to its current working directory. >> >> Regards, >> >> Matt. > > I did some tests and, as you said, the command was right, but I agree with > the user that opened that ticket: "It is strange to me that ln follows > relativity differently than other unix commands. "
Nitpicking a little -- ln doesn't; the kernel does. Calling readlink(2) on the symlink will fill out the passed-in buffer with "../usr/bin/cpp", so the data in the symlink "file" is definitely still a relative path. When you try to dereference the symlink, the kernel has two choices. It can either use the current working directory as the base for the path resolution, as it does for normal filenames, or it can use the symlink file itself. Using the cwd would mean that relative symlinks would become almost useless, as they can always be referred to with different working directories, and the relative path in question would only exist from one of those potential places. Because the symlink file contents are a lot more persistent than a pathname passed to a command and from there to a syscall like open(2). :-) (...Also, I note that no one seems to get confused when the target is in the same directory as the source, like flex -> bison. That requires the same relative path behavior. Oh well.)
signature.asc
Description: OpenPGP digital signature
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
