bug-coreutils
[Top][All Lists]
Advanced

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

Re: rln, a potential new core util


From: David Laurence Emerson
Subject: Re: rln, a potential new core util
Date: Wed, 22 Feb 2006 11:45:18 -0800
User-agent: KMail/1.7.2

Hi Pádraig,

Thanks for your reply, and for your suggestions!

I'm curious, have these issues come up before? Might I find a similar 
conversation thread by searching in the archives? Well, anyway, here goes...


> Could you not use `cp -s` to achieve what you want?

cp "can make relative symbolic links only in [the] current directory".

> Personally I would prefer the longer "for" syntax

> >#      "for i in E2 E3 E4; do ln -s b/c/d/e/$i /a; done")

The problem with the "for" operation is that the destination path (in this 
case, "b/c/d/e/$i") cannot be specified using tab completion. It's also not 
at all obvious to newbies.

I found myself wanting this on an almost daily basis, so I figured there might 
be an unrealized need for it. I would even argue that the behavior I've 
suggested and implemented is more appropriate for "ln -s" than the current 
implementation of "ln -s".

To illustrate: if I have a file "/a/b" and my pwd is "/a" then I can do:
mv b /c
cp b /c
ln b /c
and all of these will have a similar effect -- some representation of the 
file /a/b will be found at /c/b  (or else the operation will fail and return 
an error message)

However, "ln -s b /c" has the unexpected, inconsistent and probably undesired 
result of placing a dead symlink b -> b in the /c directory. It would be much 
more convenient and consistent if "ln -s" had results similar to cp, mv, and 
link.

Additionally, cp, mv and ln will all refuse to operate on a file that does not 
exist, while "ln -s" will make a link regardless. (Of course this behavior is 
useful sometimes, but it's inconsistent with the other operations. It would 
be more appropriate to require a flag to force creation of dead symlinks.)


Of course, "ln -s" is what it is, and it would probably mess a lot of people 
up if its behavior changed. So I wrote rln -- and I actually think it is more 
useful than "ln -s". But if there's not another voice of support out there, 
I'll give it a rest.

~David.

P.S.  Thanks especially for sending your reply to my address as well as the 
list.


On Wednesday 22 February 2006 2:45 am, you wrote:
> David Laurence Emerson wrote:
> 
> ># rln by David Laurence Emerson <address@hidden>
> ># version 0.01
> ># 2006-02-21
> >#
> ># This bash script is insanely slow and would be well replaced by a c
> ># implementation.
> >#
> ># rln stands for "relative (sym)link".  It helps create symlinks by
> ># intelligently finding an efficient relative path.
> >#
> ># Suppose you have a directory structure "/a/b/c/d/e".
> ># Within "e" there are several files E1 E2 E3 E4 E5 E6.
> ># Now, say you want quick access to several "E" files from within "/a"
> ># One convenient way to achieve this is by making a few symlinks.
> >#
> ># It would be nice to "cd /a/b/c/d/e" and "ln -s E2 E4 E6 /a"
> ># But that makes links like E4 -> E4 instead of E4 -> b/c/d/e/E4
> ># With "ln -s" you must explicitly specify each path relative to "/a",
> ># necessitating many keystrokes:
> ># "ln -s b/c/d/e/E2 b/c/d/e/E4 b/c/d/e/E6 /a"
> ># (or something silly like
> >#      "for i in E2 E3 E4; do ln -s b/c/d/e/$i /a; done")
> 
> Thanks for that. I'm not sure how useful it is though.
> Could you not use `cp -s` to achieve what you want?
> Personally I would prefer the longer "for" syntax
> rather than pollute the namespace with another
> command for a not very common operation.
> Also you may be interested in the findbl component of fslint:
> http://www.pixelbeat.org/fslint
> 
> thanks,
> Pádraig.
> 
>






reply via email to

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