Thanks a lot for your reply. Yes, I agree that, there is no point to change the behaviour (even though I think that the current behaviour is wrong). [A new command could keep the same interpretation of symlinks, merely changing the way in which they are created.]
I do think that a change to the documentation would be good (for both info and man). While I can't put it as clearly as I would like, may I propose:
-----------------------------------------------------------------
Symbolic links are name translations for the file. They are "redirects" which are relative to the position of the symlink itself. This is sensible, but not (intuitively) consistent with the normal methods of referring to files and paths.
ln -s TARGET LINK_NAME is best understood as a redirection sign located at LINK_NAME pointing to "TARGET". In other words, the TARGET argument to ln -s is the "wording on the redirect sign", NOT (as might be expected), the actual location of the desired target.
Hard links do NOT behave the same way. To link the file ./foo by the link in ./xyz named bar i.e to get ./xyz/bar -> ./foo we can do:
ln foo xyz/bar #creates the WORKING hard link
#between ./foo and ./xyz/bar
ln ../foo xyz/bar #no such file or directory ../foo
ln -s foo xyz/bar #creates the BROKEN symlink
# ./xyz/foo -> ./xyz/bar
ln -s ../foo xyz/bar #creates the WORKING symlink
# ./xyz/bar -> ./foo
It is the hard link behaviour which is "intuitive" and consistent with
normal behaviour; creation of symbolic links at first appears inconsistent.
(This problem only occurs for
*symlinks
*when LINK_NAME isn't in the current directory. )
-----------------------------------------------------------------
Also, I looked at 'info ln' on my system (Mandrake 9.0)
ln (fileutils) 4.1.11. This states, as its last line:
------------------------------------------------------------------
ln -s a b .. # creates links ../a and ../b pointing to ./a and ./b
------------------------------------------------------------------
I disagree! It does exactly the opposite.
Best wishes
Richard
Bob Proulx wrote:
Richard Neill wrote: First, thanks for the report. But I don't think it would be possible to change the behavior now after 20 plus years of the current behavior. change in behavior like this would need to be a new command entirely so as not to conflict with established methods.[...out of order quotes...]Symlinks seem to be like relative links in html, as opposed to the normal way of referring to paths in bash.
Yes, exactly. You have it. They are name translations for the file.ln -s foo bar #does what is expected lns -s foo xyz/bar #does not do what is expected.That creates a symbolic name translation for bar that points to "foo" because you told it "foo". Obviously you are asking it to change the translation so that it points to "../foo" from your example. I can see your point. But think about it another way. The command is literally doing exactly what you told it to do. The translation is to "foo" not to "../foo" because you told it exactly that. Perhaps if BSD implemented symbolic links that way we would all be using them that way today. But they did not. And so we are not.Another thing which is not clear is the difference between relative symlinks and absolute paths in symlinks. Eg:
ln -s foo bar #breaks when bar is moved elsewhere
#(in the general case).
ln -s /home/me/xyz/foo bar #doesn't break if bar is moved
#elsewhere.
But that does break if you move both foo and bar elsewhere. Most of the behavior you are talking about is really a function of the filesystem which is plugged into the kernel. The commands really can't change that. The semantics of the filesystem would need to be different.Ideally, I'd like to see the behaviour change, but otherwise, please document it.
The man page is automatically generated using 'help2man' from the --help output of the program. That keeps the man page up to date with respect to the options. Most of the documentation exists in the info pages. Patches to improve the documentation, especially the texinfo documentation, are always appreciated. Bob
_______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
