Bash – symbolic link to a directory and relative path

bashcd-commanddirectoryshellsymlink

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?

Best Answer

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 "..".

Related Solutions

Make a symbolic link to a relative pathname

If you create a symbolic link to a relative path, it will store it as a relative symbolic link, not absolute like your example shows. This is generally a good thing. Absolute symbolic links don't work when the filesystem is mounted elsewhere.

The reason your example doesn't work is that it's relative to the parent directory of the symbolic link and not where ln is run.

You can do:

$ pwd
/home/beau
$ ln -s foo/bar.txt bar.txt
$ readlink -f /home/beau/bar.txt
/home/beau/foo/bar.txt

Or for that matters:

$ cd foo
$ ln -s foo/bar.txt ../bar.txt

It's important to realise that the first argument after ln -s is stored as the target of the symlink. It can be any arbitrary string (with the only restrictions that it can't be empty and can't contain the NUL character), but at the time the symlink is being used and resolved, that string is understood as a relative path to the parent directory of the symlink (when it doesn't start with /).

Directory – Why Can’t List File/Directory Relative to .. from a Symlink Directory

It is special behavior of bash's cd builtin; the relative file behavior is the natural one. Once you follow a symbolic link, you are in the actual path of the target and the original path information is lost; but if you use bash or zsh to cd there then the shell remembers the original path and uses it in future relative cd commands. But not in relative filename references, because bash doesn't actually know if you intended a filename or something else.

If you look at the cd documentation in bash, you'll see there are -L and -P options which tell it whether to use "logical" (remembering the original path) or "physical" (using the filesystem's idea) paths.

If you need to have the "logical" behavior at all times, you need to use a --bind mount (on Linux; Solaris and other OSes call it "loopback" or other things) instead of a symlink.

Best Answer

Related Solutions

Make a symbolic link to a relative pathname

Directory – Why Can’t List File/Directory Relative to .. from a Symlink Directory

Related Question