[Top][All Lists]

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

Re: command "ls" bug

From: Bob Proulx
Subject: Re: command "ls" bug
Date: Sun, 30 Dec 2007 10:36:14 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

ethan wrote:
> i use 'ln'  command as follow:
> touch a   <-establish a new file

Okay so far.

> ln -s a this <-"this" is a directory and it's in current directory

Okay.  This will create a symlink ./this/a with a value of "a".  That
is almost certainly not what you want to do.

> cat this/a  <-reveal the link file
> cat: a: the layer of link is too much

Right.  In the "./this" directory the "./a" symlink points to "a"
making it refer to itself.  That creates an infinite loop of
redirection.  You can see this by using "ls -l" to list the symlink.

  $ ls -log this
  lrwxrwxrwx 1 1 2007-12-30 10:26 a -> a

See that the name points to itself.

Symbolic links are name translations.  They always refer to the file
in relation to the directory that they are located.  If in the "this"
directory you wish a symlink "a" to refer to the "a" in the directory
above "this" then the value of the symlink must be "../a".

  $ touch a
  $ mkdir -p this
  $ ln -s ../a ./this/a

If you make the symlink from a different directory then the value of
the symlink and the relative location will not be the same.

Sometimes people understand this more easily if they change directory
to their target directory first and then make the symlink because then
the relative location to the source and the string for the value are
the same.

  $ touch a
  $ mkdir -p this
  $ cd this
  ln -s ../a ./a

Note that the value of the symlink was the same regardless of the
current working directory.  It is a name translation and does not
need to refer to an existing file at the time that it is created.

You might also wish to read a previous discussion of this issue:



reply via email to

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