symbolic link to a directory and relative path

Question

I've created symlink with absolute path to the directory (Blink) and have for example following tree:

$ ls -l /tmp/A
total 0
lrwxrwxrwx 1 root root 6 Apr  3 12:27 Blink -> /tmp/B
-rw-r--r-- 1 root root 0 Apr  3 12:27 foo

$ ls -l /tmp/B
total 0
-rw-r--r-- 1 root root 0 Apr  3 12:27 bar

then I go to /tmp/A and change directory to Blink:

$ cd /tmp/A
$ pwd
/tmp/A
$ cd Blink
$ pwd
/tmp/A/Blink

cd .. returns me to /tmp/A but if I type for example ls ../foo I'll got error:

ls: ../foo: No such file or directory

builtin cd command resolve path as needed, but external ls consider the .. as up-level of /tmp/B and therefore cannot find foo.

What is the problem here? Can I get the foo file from /tmp/A/Blink by relative path like ../foo?

Solution 1

I don't think you can do this. Shells nowadays keep track of how they got where they are, they keep track of current working directory by name, rather than just relying on file system and OS to keep it. That means the built-in cd can go "back up" the symbolic link, rather than just following ".." chains directly.

But when you run ls ../foo, ls isn't aware that the shell got to a directory by following symbolic links. ls will do a stat() on "../foo". The ".." part comes from the current directory, which has only a single ".." entry for it's parent. The whole symbolic link thing doesn't change the way directories have a single "." and a single ".." entry. Symbolic links let the kernel insert an extra layer of indirection into file paths. When you pass "../whatever" to open() or stat(), the kernel just uses the current working directory of the process doing the call to figure out which single directory is named by "..".

Solution 2

The shell stores the current working directory in $PWD. That's what's used for the shell builtins cd and pwd, and it treats symlinks as normal directories, as you've seen. Sometimes this is helpful, sometimes not.

You can find the real directory using pwd (type help pwd for more details):

$ pwd
/tmp/A/Blink
$ pwd -L
/tmp/A/Blink
$ pwd -P
/tmp/B

Likewise, cd has an option -P (again, help cd is your friend):

$ cd /tmp/A/Blink
$ pwd
/tmp/A/Blink
$ cd -P ..
$ pwd -P
/tmp

Finally, you can turn off the "feature" altogether:

$ set -P
$ cd /tmp/A/Blink
$ pwd
/tmp/B

Solution 3

Bruce and ams gave beautiful answers explaining the behavior behind. But to actually do the ls ../foo you were asking, you could go with something like

ls $(dirname $PWD)/foo

Solution 4

You can't do it, because /tmp/A/Blink is actually /tmp/B. So, ls ../A/foo does work.

You may instead find it useful to be able to cd to the real /tmp/B directory, rather than the aliased /tmp/A/Blink. To do that, you can use the following function instead of cd (which you can put into your .bashrc)

lcd() { cd $(readlink -f "$1"); }

lcd, of course, works for bothe normal and symbolic-linked directories.
Note: readlink -f acts on the final target of the link (when links are daisy-chained)..

View more solutions

Comments

[jw013]

cd -P seems simpler.

[Peter.O]

@jw013: You are right; it is. I wasn't aware of it.. thanks..

[user478681]

Thanks, I'm aware about set -P feature, but was confused by ls command behavior...

[ams]

Like I said, use set -P and ls behaviour starts to make sense. :)