bug-coreutils
[Top][All Lists]
Advanced

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

bug#21290: ln --relative bug?


From: Bob Proulx
Subject: bug#21290: ln --relative bug?
Date: Tue, 18 Aug 2015 16:54:48 -0600
User-agent: Mutt/1.5.23 (2014-03-12)

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





reply via email to

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