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.
