symbolic links & `..' entry

[Ivan Shmakov]

>>>>> "PT" == Pierre THIERRY <nowhere.man@levallois.eu.org> writes:

 IS> Yes, shells oftenly do that.  Note, however, that almost every
 IS> other program isn't so smart:

 >> $ mkdir -p a/b c/d
 >> $ cd c/d
 >> c/d $ ln -s ../../a/b e
 >> c/d $ cd e
 >> c/d/e $ ls ../
 >> b
 >> c/d/e $ 

 IS> Would `ls' parse `..' by itself, `e' would have been shown instead.

 IS> And again, I'm not about to /deny/ such ``lexical'' interpretation
 IS> of `..', but it's not clear to me, which benefits it would bring
 IS> (or, which things it would break?)

 PT> The benefit seems obvious to me from your example: it would make
 PT> symlinks a less leaky abstraction. And I'm curious where the
 PT> current behaviour ls exhibits here is needed.

        ... Yet another example:

$ mkdir -p a/b a/x c/d
$ touch a/x/y
$ cd a/b
a/b $ ln -s ../x z
a/b $ cd ../..
$ ls a/x/
y
$ ls a/b/z/
y
$ 

        Now, let us repeat the steps from the previous example:

$ cd c/d
c/d $ ln -s ../../a/b e
c/d $ cd e
c/d/e $ 

        Now, $ ls z/ will show us `y', just as expected.  Would `..' be
        interpreted lexically, it would break the things, since
        `c/d/e/z', being a symbolic link to `../x', would lead us to
        non-existent `c/d/x'.

        I guess, there could be some examples related to the use of GNU
        Arch, since it depends on ascending directory tree recursively
        to get access to its control files, `{arch}/'.

        ... Doesn't it look like both interpretations could be useful?