[Top][All Lists]
[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.
>
>