Re: [RFC PATCH] ln --relative: do not dereference target symlinks unless -L is given

[Pádraig Brady]

On 07/16/2013 11:11 PM, Dmitry V. Levin wrote:
> I received a bug report
> (https://bugzilla.altlinux.org/show_bug.cgi?id=29115) saying that
> 'ln --relative' behaviour is counterintuitive with regard to
> dereferencing target symlinks: ln -r should not dereference
> source file symlinks unless -L option is given.
> 
> I agree with this bug report; --relative is a new option, so changing its
> default behaviour wrt dereferencing target symlinks may be considered as a
> bug fix, but I'm not quite sure about that.  If there is an understanding
> that 'ln -P -r' (and maybe 'ln -r') should be changed to not dereference
> source file symlinks, I'll update documentation describing -L, -P and -r
> options.

So this was discussed at:
http://lists.gnu.org/archive/html/coreutils/2012-02/msg00167.html

The summary of that is `ln -r` behaves as it does, as there
are various ways to resolve the target (with/without symlinks,
or resolving '../' components before/after symlinks).

So now it resolves the targets as per the default mode of `realpath`.
To get more control one can use $(realpath -s ...) etc.
The existing behavior is documented unambiguously in the info docs as of:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=34023817

So I'd be inclined to leave the default behavior.

As for adding CAN_NOLINKS when -P specified,
I did mention that as an option in the first link above.
Though I mentioned it wasn't ideal as the current -LP
behavior is restricted to hardlinks (as also specified in usage()).

Consider also just using CAN_NOLINKS with:

  $ ln -sr /path/with/symlink/../file /tmp/file.sl
  $ readlink /tmp/file.sl
  ../path/with/file

I.E. a required symlink is elided in this case.
So that suggests, to leave as is and keep the more
complicated options to ln -sr $(realpath ...) ?

cheers,
Pádraig.