[Top][All Lists]

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

symbolic links & `..' entry

From: Ivan Shmakov
Subject: symbolic links & `..' entry
Date: 09 Feb 2007 01:32:11 +0600
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

>>>>> "PT" == Pierre THIERRY <> 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/
$ ls a/b/z/

        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?

reply via email to

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