Re: symlink weirdness

[Roger Dahl]

Tim Smith <reply_in_group@mouse-potato.com> wrote in message 
news:<70E1d.1386$n16.153@newsread2.news.atl.earthlink.net>...
> On 2004-09-14, Roger Dahl <rdnews@dahlsys.com> wrote:
> > If your current directory is A and you want to create a relative symlink
> > to a file in directory B in directory C, you need to type the path as it
> > would look from C, not from A.
>  ...
> > This oddity complicates writing scripts that create symlinks.
> 
> This does not complicate writing scripts.  It makes writing scripts easier,
> because it makes "ln -s" predictable.

Hi Tim,

Could you expand upon how 'ln' is more predictable without the
suggested feature?

> > We need more intelligent 'ln' and 'cp -s', that, given paths from A to B
> > and from A to C can create links between B and C.
> >
> > Any thoughts?
> 
> What a horrible idea.  "ln -s foo bar" is very simple now: it makes a
> symlink at bar containing foo.  This is what you want in scripts. 

In my experience, scripts that create symlinks often manipulate two
paths, pointing to two directory structures. To create a symlink, it
becomes necessary to create the path pointing between them. That path
is used only as an argument to 'ln'.

> 
> The correct way to do what you want is to write a *separate* program to
> compute relative paths, e.g., 
> 
>     findrel B C
> 
> which would return a relative path to C starting from B, and then do this
> in your script:
> 
>     ln -s `findrel B C` B/whatever

I like that idea but I think it would be even more handy to have a
switch in 'ln' that would tell it to interpret TARGET to be relative
from the current directory (if it is relative) and calculate the path
to store in the link.

Roger