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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21290 in the body.
You can then email your comments to 21290 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Matteo Cerutti <matteo.cerutti <at> hotmail.co.uk>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: ln --relative bug?
Date: Tue, 18 Aug 2015 13:04:38 +0200

[Message part 1 (text/plain, inline)]

Hi,

is this the expected behavior?

# ln -s /tmp/non_existent_file b
# ln -s --relative b c
# ls -lrth
total 0
lrwxrwxrwx. 1 root root 22 Aug 18 13:03 b -> /tmp/non_existent_file
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.

Cheers,
Matteo
 		 	   		  

[Message part 2 (text/html, inline)]

Message #8 received at 21290 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Matteo Cerutti <matteo.cerutti <at> hotmail.co.uk>, 21290 <at> debbugs.gnu.org
Subject: Re: bug#21290: ln --relative bug?
Date: Tue, 18 Aug 2015 13:17:25 -0700

tag 21290 notabug
close 21290
stop

On 18/08/15 04:04, Matteo Cerutti wrote:
> Hi,
> 
> is this the expected behavior?
> 
>     # ln -s /tmp/non_existent_file b
>     # ln -s --relative b c
>     # ls -lrth
>     total 0
>     lrwxrwxrwx. 1 root root 22 Aug 18 13:03 b -> /tmp/non_existent_file
>     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?
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.

thanks,
Pádraig.
> 
> Cheers,
> Matteo

Message #11 received at 21290 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 21290 <at> debbugs.gnu.org
Cc: Matteo Cerutti <matteo.cerutti <at> hotmail.co.uk>
Subject: Re: 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.