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 <[EMAIL PROTECTED]> > ># 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. > > _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
