[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Pádraig Brady
Subject: Re: [PATCH v2] ln: add the --relative option
Date: Fri, 30 Mar 2012 10:23:43 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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) ...`


reply via email to

[Prev in Thread] Current Thread [Next in Thread]