bug-fileutils
[Top][All Lists]
Advanced

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

Re: Bug with ln?


From: Bob Proulx
Subject: Re: Bug with ln?
Date: Tue, 16 Jan 2001 13:22:49 -0700

Alain

> I'm not sure if it is a bug, but the 'ln' command is not working that
> way that I expect.

Thank you for your report.  The behavior you are seeing is normal.  I
believe you are just misunderstanding how symlinks work.  This really
has nothing to do with ln or fileutils.  This is just BSD symbolic
link semantics.

> If I do the following:
> 
> [ ]$ cd /home/apt
> [home/apt]$ ls -l example
> -rw-r--r--   1 apt      apt             0 Jan 15 22:45 example
> [home/apt]$ mkdir test
> [home/apt]$ ln -s example test/example
> [home/apt]$ ls -l test/example
> lrwxrwxrwx   1 apt      apt             7 Jan 15 22:46 test/example -> example

In the test directory you now have example symbolically linked to
itself.  'cd test', 'ls -l'  The name of the link is the path relative
to the target that will find the source.

> i.e. because I haven't fully specified the path of the first argument to
> ln, 'example', ln assumes that it is in the same directory as the second
> argument, and the symbolic link generated is an invalid link.

Yes and no.  You are right that it is in the same directory.  But it
is not because you did not fully specify it.  It is because you
specified it in the wrong directory.

> If I continue the above commands with the following:
> 
> [home/apt]$ rm test/example
> [home/apt]$ ln -s ./example test/example
> [home/apt]$ ls -l test/example
> lrwxrwxrwx   1 apt      apt             9 Jan 15 22:46 test/example -> 
> ./example
> 
> Even this does not give the desired result!

You are thinking that you need to 'ln -s' the first file to the
second.  Therefore you are finding the first file and grabbing a hold
of it tightly and ln -s it to the target.  But that is not how
symbolic links work.  Symbolic links work by name.  It is only the
name that ties it to the source.  And they may only match a real file
when looked at from the perspective of the directory where the target
resides.  Try this along with your normal tests.

  rm test/example
  ln -s ../example test/example

This should link those two files together by name.  But ../example
does not match any file at the level you are at.  It only matches from
the perspective of the target directory.  And there is the rule.  Make
the name of the source as needed within the perspective of the target.
This is usually easier to understand if you cd to the target directory
first and work from there.  At that point the source will match a real
file.

  cd test
  ln -s ../example .

> Only 'ln -s /home/apt/example test/example' works.

A fully qualified path is fully qualified everywhere.  Which is why
that worked for you.  However, I recommend against it.  If you ever
move that directory your fully qualified paths will be broken.  Also,
this will not work across NFS mounts or other remote filesystems where
this path needs to be /net/host or possibly other paths.  Using a full
path almost guarentees future trouble.  Whenever possible it is best
to stick with relative symlinks.  Those are simple and well behaved.
It is hard to get in trouble with a local relative symlink.

Hope this helps.

Bob



reply via email to

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