Re: "ln -s" seems counterintuitive

[Richard Neill]

Dear Bob,

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