Braun Gabor wrote:
> The info node "ln invocation" has this example at the end:
>
> ln -s a b .. # creates links ../a and ../b pointing to ./a and ./b
>
> I have tried it. The result: ../a pointing to itself and ../b
> pointing to itself. Such self-referencing links are totally
> useless.
Thanks for the report. But what you are seeing is not a bug.
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.
As you reported the example the result is not useful. However it is
correct. The upstream documentation that will be in the next Debian
release has been expanded to say this more explicitly. Here is the
current documentation.
Examples:
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 file names don't move well.
ln -s $(pwd)/a /some/dir/
Better Example:
# Relative file names survive directory moves and also
# work across networked file systems.
ln -s afile anotherfile
ln -s ../adir/afile yetanotherfile
> ln -s a b .. # creates links ../a and ../b pointing to ./a and ./b
> ...
> I expected that the result is ../a pointing to a in the
> current directory, i.e the directory in which the command was issued.
> Similarly for ../b.
Your expectations were incorrect. That is not what happens. That
behavior would be completely different from the traditional behavior
for 'ln' creating symlinks.
This new behavior that you are desiring has been suggested before
and if someone were motivated to write the code, tests and docs for it
then I am confident that it would be accepted in the upstream project.
But until someone does those things it then it does not exist. In any
case it is not a bug in the current code. The program is behaving as
it should behave in your case.
> My general experience is that
>
> ln -s relative/path/to/target linkname
>
> interprets the path to target relative to the parent directory of
> linkname and not relative to the working directory.
That is correct. You have it the -s option which specifies this
behavior. It is creating a symbolic (name) translation because of the
presence of the -s option.
> In contrast
>
> ln relative/path/to/file linkname
>
> interprets the path relative to the working directory.
That is correct. You used it in the default mode which hard links
files.
You are confusing file name linking with file inode linking. Those
are really to completely different things and are only vaguely
related. In many ways it is unfortunate that the same 'ln' command
implements both operations. Really for the jobs they are doing they
should be in two completely different commands.
'cp', 'mv', 'ln', 'rm', 'chmod', etc. all operate on files and the
source arg is relative to the current directory. Those are the old
commands of the unix system. They are all mostly consistent on how
they operate.
Symbolic links were developed at Berkeley and came much later. They
were bolted onto the existing commands. That is why it requires an
option to 'ln' to create symbolic links. When the option is specified
it changes the behavior of ln and it now creates symbolic name links
between files instead of hard inode links between files. The -s
option turns on this mode of operation.
Bob
--
Bob Proulx <[EMAIL PROTECTED]>
http://www.proulx.com/~bob/
CP-ASEL-IA-Tailwheel-Glider
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
