CentOS - May 2005 - When “..” isn’t the same? (not a problem

I don?t understand why ".." isn?t working the same way for
"ls" and "cd" when inside
a symbolic link. The reason I ask is that I made a link to a directory with some
scripts that saves output in "../output.txt" and I could not find the
output until I
found that ".." isn?t the directory you see when you do a $pwd. I
solved the problem
by making a directory and then make a link to each script in there.

I would just like to know:
1) if there is a good reason to this behaviour.
2) if there is a rule, so you know when ".." is level up from $ pwd
and when it is
one level up from the link target.
3) if there is an alternativ way to point to the parent directory.

Personally I can't see why you would ever need ".." to be one
level up from the link
target.

Example:
$ ln -s /home link_to_home; cd link_to_home

$ ls ..
bin   dev  home    lib   misc  


$ cd ..;ls
link_to_home


Have a nice weekend
Ulrik







-- 
This message has been scanned for viruses and
dangerous content by OpenProtect(http://www.openprotect.com), and is
believed to be clean.

Ulrik S. Kofod wrote:
> I don?t understand why ".." isn?t working the same way for
"ls" and "cd" when inside
> a symbolic link.
"cd" is shell builtin that attempts to be (too) smart.  Since it is 
shell builtin, it is able to remember where you think you are.  There is 
an extra code to implement this feautre.  "pwd" builtin also behaves
the
same.  Try "pwd" followed by "/bin/pwd" to see the
difference.  Former
will return shell's best guess where you thing you are (and really this 
is just a best guess).  Later will return where you actually are.

While bash implements "ls" as shell builtin too, it does not attempt
to
be "smart".  When you do "ls .." it will simly read entry
for ".." in
the actual file system structure which is going to point one directory 
up from your actual position in file system.

Same goes for /bin/ls (which is a binary), or any other binary on the 
system, that has no reliable way of knowing where you think you are 
(unlike shell builtins that have the luxury of history).  See the pwd 
example described earlier.  No, $PWD is not reliable way of knowing 
where you think you are.  $PWD is set by particular shell, and different 
shells handle it differently (if they define it at all).  Program that 
would rely on it would produce different results for users of different 
shells.  Not a good thing.

Something like this would make your script work without creating links 
for every possible file, buy you better make sure $PWD is set the way 
you want it to be set by the interpretter that executes your script, and 
that interpretter acutally inherits value of $PWD that was set by 
calling shell:

$ mkdir -p a/b/c/d
$ ln -s ./a/b/c/d .
$ cd d
$ ls -l `dirname "$PWD"`
$ echo test > "`dirname "$PWD"`/test"

Or more complicated way that does not rely on existance and/or 
correctness of $PWD:

$ mkdir -p a/b/c/d
$ ln -s ./a/b/c/d .
$ ln -s ../../../.. ./a/b/c/d/up
$ cd d
$ pwd
/tmp/d
$ /bin/pwd
/tmp/a/b/c/d
$ ls -l up/.
$ echo test > ./up/test
$ cd -
$ cat test

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote
Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7