bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "ln -s" seems counterintuitive


From: Bob Proulx
Subject: Re: "ln -s" seems counterintuitive
Date: Mon, 17 Feb 2003 18:14:54 -0700
User-agent: Mutt/1.3.28i

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]