Robert Miesen wrote: > I checked the FAQ for ln and it would appear that what I'm calling a > "bug" GNU calls a "feature."
GNU is implementing previously existing behavior. Symbolic links originated in BSD. It is a BSD feature that migrated to System V and then to GNU and elsewhere. The behavior is now standardized by POSIX so that it will always be the same everywhere and it is possible to write portable scripts that behavior the same everywhere. > However, I looked into the manuals (both man and the more favored > info pages) and the manual does not make clear that the argument > provided to TARGET needs to be reachable from LINKNAME. As an aside let me note that suggestions for improvements to the documentation are always appreciated. > For example, this is what is in the info page regarding how I am > invoking the ln command: > > * If two file names are given, `ln' creates a link to the first file > from the second. Hmm... That refers to the default 'ln' behavior *without* the -s option. Before the -s option appeared in the tool that statement was true. But with the addition of the -s option that statement is not always true. It doesn't apply when the -s option is given because that changes the behavior from being a hard link to a symbolink link. Instead of actually placing another link to the file in the directory it places a special file that stores that value given in it. Usually the value given is used to point to a file but it is a generic symbol and may be anything. > So in the manual, it is not immediately clear to someone just > referencing the manual that if TARGET does not exist from DIRECTORY, the > link will remain broken until the TARGET exists in DIRECTORY. Trying to document all of the existing behavior has always been hard and problematic to get right. > That even seems quite counterintuitive, since it seems more like the > argument I passed in to ln would be relative to the cwd (Current > Working Directory), not DIRECTORY (the cwd file I'm talking about > can be found in /proc/runningProcess/). Again, this is the way it was originally implemented a couple of decades ago in BSD. The 'ln -s' doesn't actually link two files together but instead creates a special file with the string value given. The filesystem will redirect through the value of the symbolic link for most filesystem operations. The symlink doesn't need to point to an existing file. It is a name resolution which happens at runtime. It might resolve to different files at different times. Normally it is a path to another file. But you can give it anything you want there. You can store the name of your dog there if you wish or use it to store a very small shopping list. It is more flexible and more useful the way that it is implemented. It is often used for lock files storing the name of the locker for example. But that flexibility means that you depending upon what you want to do with it that you might or might not do what you wanted to do. > Thank you for your kind and informative email. It has put into > perspective this "bug" (or "feature" depending on your interpretation.) Most importantly not having it work this way would break a lot of legacy code that expects it to work the way that it does. Symlinks have been "an addition" to the operating model since the feature was introduced in BSD and because it was an addition has never been seamlessly integrated. And it can't now because the filesystem model with the symlink addition has seen such wide use that any changes would be very disruptive. Bob _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
