GNU bug report logs - #21290
ln --relative bug?

Previous Next

Full log

View this message in rfc822 format

From: Bob Proulx <bob <at> proulx.com>
To: 21290 <at> debbugs.gnu.org
Cc: Matteo Cerutti <matteo.cerutti <at> hotmail.co.uk>
Subject: bug#21290: ln --relative bug?
Date: Tue, 18 Aug 2015 16:54:48 -0600

Pádraig Brady wrote:
> Matteo Cerutti wrote:
> >     # ln -s --relative b c
> >     lrwxrwxrwx. 1 root root 20 Aug 18 13:03 c -> ../non_existent_file
> > shouldn't c point to b?
> > 
> > Mind that it doesn't happen when the --relative option is absent.
> 
> Are you referring to the non_existent_file
> or the fact that the symlink is dereferenced before the relative adjustment?

Regarding:

  ln -s --relative b c

I think the expectation of least surprise is that --relative would
restrict itself to changing only the relative path of "b".  Since "b"
is already a relative path that --relative would have nothing to do
there.  And indeed when I saw that it surprised me.  (Until I read the
documentation.)  Because now it is order dependent.

  mkdir /tmp/test
  cd /tmp/test
  ln -s --relative b c
  ln -s /tmp/non_existent_file b
  ls -ldog b c
    lrwxrwxrwx 1 22 Aug 18 16:30 b -> /tmp/non_existent_file
    lrwxrwxrwx 1  1 Aug 18 16:29 c -> b
  ln -sfn --relative b c
    lrwxrwxrwx 1 17 Aug 18 16:31 c -> non_existent_file
  rm -f c
  ln -s --relative b c
    lrwxrwxrwx 1 1 Aug 18 16:38 c -> b

Without reading the documentation for --relative I found that surprising.
It isn't behavior that I would ever knowingly want to use.

> If the latter then that's expected as detailed at:
> 
>   http://www.gnu.org/software/coreutils/ln
> 
> Also included there is an example using `realpath`
> which gives more control over the dereferencing.

The documentation does clearly state that --relative does *both*
conversion of the value to a relative path and to dereference using
realpath.

     Relative symbolic links are generated based on their canonicalized
     containing directory, and canonicalized targets.  I.E. all symbolic
     links in these file names will be resolved.  *Note realpath
     invocation::, which gives greater control over relative file name
     generation, as demonstrated in the following example:

In hindsight perhaps it should have been called --relative-realpath
instead of just --relative.  Because now eventually it will be
suggested that --relative-only would be a useful option to only create
relative paths only.  Oh well.  (shrug)

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.