[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH] ln --relative: do not dereference target symlinks unless
Re: [RFC PATCH] ln --relative: do not dereference target symlinks unless -L is given
Wed, 17 Jul 2013 03:37:52 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
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
So this was discussed at:
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:
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
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 ...) ?