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
