[prev in list] [next in list] [prev in thread] [next in thread] 

List:       coreutils
Subject:    Re: [PATCH v2] ln: add the --relative option
From:       <P () draigBrady ! com>
Date:       2012-03-30 9:23:43
Message-ID: 4F757B9F.7080707 () draigBrady ! com
[Download RAW message or body]

On 02/24/2012 01:04 PM, Eric Blake wrote:
> On 02/24/2012 04:11 AM, Pádraig Brady wrote:
>>>
>>> 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.
> 
> Furthermore,
> 
> ln ../a b/c
> 
> states that ../a must exist, and that b/c now names the same inode, while
> 
> ln -s ../a b/c
> 
> states that b/c is a symlink containing the contents ../a, which means
> b/c resolves to b/../a, which is (usually) a different location than
> ../a.  That is, the difference stems from the fact that 'ln' must
> resolve the target, and once the target is resolved, no name is stored
> in the destination; while 'ln -s' must not resolve the target, and the
> target becomes relative to the destination, not the current starting
> point.  Therefore, having the ability to create a relative symlink to an
> existing file but residing in a directory that you are not currently in
> becomes tricky to think about, so having ln add options to make the task
> easier seems worthwhile.
> 
> I also wonder if it can go both directions; not only can I envision
> 
> ln -s --relative /abs/path/to/a b/c
> 
> as a way to create b/c as the minimal relative path in relation to b,
> rather than as an absolute path, but it might also make sense to have
> 
> ln -s --absolute ../a b/c
>
> which says to make b/c a symlink to the absolute path of '../a' as
> resolved with respect to the current directory, rather than to the
> normal semantics of not resolving ../a and instead installing the
> symlink relative to the destination directory b.
> 
> Or looking at it slightly differently, maybe the thing to do is propose
> two orthogonal switches - one switch that says whether the source name
> is to be treated relative to the current working directory rather than
> as a raw string that will be applied relative to the target directory,
> and one switch that says whether the symlink being installed is relative
> or absolute, regardless of whether the command line gave it in a
> different form.
> 
> Certainly some food for thought.
> 

Sorry for not replying to this earlier.
I didn't think --absolute was necessary as ln --relative is more
of a convenience than a fundamental operation.
I.E. `ln --relative ..` is easier than `ln $(realpath --relative-to $(dirname)) ...`
and this would be a very common usage too.
However `ln --absolute` is equivalent to just `ln $(realpath) ...`

cheers,
Pádraig.


[prev in list] [next in list] [prev in thread] [next in thread]