coreutils
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: Re: [PATCH v2] ln: add the --relative option
Date: Fri, 24 Feb 2012 06:04:38 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1

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.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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