bug-coreutils
[Top][All Lists]
Advanced

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

Re: ln does not work as documented


From: William J. Bruno
Subject: Re: ln does not work as documented
Date: Tue, 7 Jun 2005 10:17:25 -0600 (MDT)
User-agent: SquirrelMail/1.4.4-2

Thanks for clarifying that.

What's misleading is when you say
>      ln -s a b ..      # creates links ../a and ../b pointing to ./a and
> ./b
I thought pointing to ./a would be an a in the current directory.

Wouldn't it be nice:
It seems that I fairly often run into situations where I wish ln had
some additional functionality, although I can't say exactly what
it should be.  But for instance, after compiling a package yesterday
with lots of executables, I just wanted to make links to all the
executables and put them in my ~/bin.  I decided to move them
instead because I could do mv a b c d e f g ~/bin.  To ln them, which I
would prefer, I have to type ln longpathname/a longpathname/b ... .
Now that I think about it, I could have defined a variable to shorten
the path name, but there were something like 8 executables.

Wouldn't it be nice if ln had an option to try to figure out
the relative path from the target dir to the cwd (and could perhaps
fall back to a hard path if necessary).



> Bill Bruno wrote:
>> The examples in the man page say I can
>> ln -s a b ..
>> and get links in ../a and ../b to ./a and ./b
>
> Yes.  Perhaps not the most useful of examples.  Suggestions for
> documentation improvements are always welcome.
>
>> but when I try it I get a link from ../a and ../b to
>> themselves, which are useless circular links.
>
> The info docs say:
>
>      ln -s a b ..      # creates links ../a and ../b pointing to ./a and
> ./b
>
> Symbolic links are purely linked by name value and nothing more.  The
> names in the examples are "a" and "b".  Those are created in the
> directory .. and they do point to ./a and ./b.  Not a useful example
> but still illustrative of what the command does.  When the target is a
> directory the new files (symlinks are special files) created will be
> named the same as the source file names.  Each one will hold the value
> of the source.
>
> Maybe it would be good to have some bad examples in the docs.
>
> Bad Example:
>
> # Create link ../a pointing to a in that directory.  Not really useful
> # because it points to itself.
> ln -s a ..
>
> Better Example:
>
> # Change to the target before creating symlinks to avoid being confused.
> cd ..
> ln -s adir/a .
>
> Bad Example:
>
> # Hard coded paths don't move well.
> ln -s $(pwd)/a /some/dir/
>
> Better Example:
>
> # Relative paths survive directory moves and also work across
> # networked filesystems.
> ln -s afile anotherfile
> ln -s ../adir/afile yetanotherfile
>
>> I'm using tcsh in linux,
>> uname -r : 2.4.21-20.EL
>
> Just fyi but neither of those two pieces of information matter.  What
> might have mattered was the version of the 'ln' command.  You can
> report it with the --version option.
>
> Bob
>





reply via email to

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