Thanks for the report and investigating GNU Emacs, Marcus!
Marcus Harnisch writes:
Evaluating the expression below leads to strange results that are
contradicting the doc-string which claims that "." and ".." would be
I suppose the problem is that this expression doesn't have
well-defined semantics since conceptually it takes you out of the file
system. Unix file systems do define this concept since all
directories have a parent pointer (AFAIK), and all set /.. to /
(AFAIK). But what this might mean in a filesystem without parent
pointers (DOS at least, also Windows NT, VMS IIRC) is unclear. On
those systems "/" is not an absolute path! (You need a drive letter.)
Note that this is a textual transformation; AFAIK the only system call
made in the function is to read /etc/passwd to expand ~USER.
The good news is that at least this is FSF compatible behavior.
I think this is a killer argument for documenting the anomoly, not
changing behavior. Of course, I'm very conservative on this kind of
Is there a practical problem you experience, or does this
inconsistency just bother you?
It doesn't occur to me why it would be difficult to return
As a matter of coding, it would be easy to make that change.
That's what I get already. Even on systems where that is not an
absolute path that's well-defined, I think, although I haven't checked
that that's the result on Windows.
Looking at the code I find this comment:
/* `/../' is the "superroot" on certain file systems. */
Is there any file system still in use with this concept?
I believe they're referring to operating systems without unified file
name spaces (typically those which use devices not mounted on the file
hierarchy), which would include Windows.
If you want to pursue this, I think you need to ask on emacs-devel.
XEmacs-Beta mailing list