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: Bob Proulx
Subject: Re: ln does not work as documented
Date: Mon, 6 Jun 2005 22:59:17 -0600
User-agent: Mutt/1.5.9i

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]