Re: [PATCH v2] ln: add the --relative option

[Pádraig Brady]

On 02/24/2012 07:58 AM, Voelker, Bernhard wrote:
> address@hidden wrote:
> 
>> With the "--relative --symbolic" options, ln computes the relative
>> symbolic link for the user.
> 
> I also like this idea.
> 
>> $ ln -s -v --relative usr/bin/foo usr/lib/foo/link-to-foo
>> 'usr/lib/foo/link-to-foo' -> 'foo'
>>
>> $ tree ./
>> ./
>> `-- usr
>>     |-- bin
>>     |   `-- foo -> ../lib/foo/foo
>>     `-- lib
>>         `-- foo
>>             |-- link-to-foo -> foo
>>             `-- foo
>>
>> 4 directories, 3 files
> 
> In this case, I am be a bit surprised that ln has created
> a symlink to the resolved target ('foo') instead of to what
> the user told us to do: '../../../bin/foo'.
> I'd have expected this only with an additional "resolve" or
> "canonicalize" option.

Yep a valid point. Extending my previous function a little...

ln--relative() {
  test "$1" = --no-symlinks && { nosym=$1; shift; }
  target="$1"; link_name="$2"
  rtarget="$(realpath $nosym -m "$target" --relative-to "$(dirname 
"$link_name")")"
  ln -s -v "$rtarget" "$link_name"
}

# ln--relative --no-symlinks usr/bin/foo usr/lib/foo/link-to-foo
‘usr/lib/foo/link-to-foo’ -> ‘../../bin/foo’

Now I am leaning towards adding the --relative option to ln as it's so useful.
However cases like this show the benefit of the more functional approach.
Do we add the --no-symlinks option to ln, probably not.
Perhaps we could key this behavior off the existing -P option of ln.
That's not ideal though.

>> +  if (relative && !symbolic_link)
>> +    {
>> +        error (EXIT_FAILURE, 0,
>> +               _("cannot do --relative without --symbolic"));
>> +    }
> 
> Why restrict this to symlinks - it could also be useful for
> hardlinks, right?

Well hardlinks reference inodes and so are independent
of any naming, whether relative or absolute etc.

cheers,
Pádraig.