Re: Difference in ln/ln -s semantics

[Jim Meyering]

Elmar Zander <address@hidden> wrote:
> as I've understood from those threads
>   http://lists.gnu.org/archive/html/bug-coreutils/2007-12/msg00211.html
>   http://lists.gnu.org/archive/html/bug-coreutils/2007-11/msg00006.html
> and the FAQ the difference in ln and ln -s behaviour is intended and not 
> fixable.
>
> To summarize: if you type
> * ln 'path1/file1' 'path2/file2', then 'path2/file2' points to
> ./path1/file1', i.e. the path is considered relative to the current

You have the right idea, but once two files are hard-linked,
there is no directionality.  Each refers to the same inode.
I.e., saying one points to the other is misleading.

> working directory (since the inode of 'path1/file1' is immediately
> resolved)
> * ln -s 'path1/file1' 'path2/file2', then 'path2/file2' points to
> path2/path1/file1', i.e. the path is considered relative to the
> directory where 'file2' resides (since just the string 'path1/file1'
> is stored somehow in 'path2/file2' and only resolved when the symlink
> path2/file2' is accessed)
>
> If you know that in the first case 'file2' is made to point to the
> same inode and in the second case just the path 'path1/file1' is
> stored in 'file2' this behaviour is ok and understandable. *But*: the
> documentation (GNU coreutils 6.10, April 2008) for 'ln' just states
> for the -s option
>
> ‘-s’, ‘--symbolic’
>     make symbolic links instead of hard links.
>
> Nothing more. For me, a statement like this usually implies that the
> two are semantically equivalent (which they are not, as
> described). So, I think that the user should be informed of this
> difference, maybe by a sentence like
>
>   Note: if 'target' is a relative path and 'linkname' does not point
> to the current directory, the created link will be relative to the
> directory  the link is created in.
>
> or
>
>   For semantic differences between ln and ln -s see the examples section.

Thanks.  Either would be good.
Would you like to adjust doc/coreutils.texi accordingly?
If you change the man page (aka --help output), bear in mind
that is should stay concise.  It does point to the complete
documentation in the info pages after all.

If so, please take a look at the contribution guidelines:

  http://git.sv.gnu.org/cgit/coreutils.git/plain/HACKING