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.
