[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1135: 23.0.60; (expand-file-name ".." "/") produces surprising resul
From: |
Stefan Monnier |
Subject: |
bug#1135: 23.0.60; (expand-file-name ".." "/") produces surprising results |
Date: |
Fri, 10 Oct 2008 13:37:25 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
> I use some code that uses (setq dir (expand-file-name ".." dir)) to walk
> up a directory tree to the root.
Was there any particular reason not to use:
(setq dir (directory-file-name (file-name-directory dir)))
> I debugged this down to the unexpected (to me) behaviour of
> (expand-file-name ".." "/")
> => "/.."
> (expand-file-name ".." "/..")
> => "/"
That's a bit problematic, indeed. The reason for the first behavior is
because there exist(ed) special file systems that were accessible under
/.. (IIRC machines at cs.cmu.edu around early 90s, maybe late 80s, had
such a distributed filesystem that allowed access to other machines via
/../<hostname>/..., maybe there were other such things). The second is
there because nobody knows what /../.. is supposed to mean in such
a context: if /.. is a mounted filesystem, then /../.. should get you
back to /; then again if /.. is really the Root, then /../.. should just
be /..; or maybe there's a hierarchy of roots so /../.. should just stay
as /../..?
> This was causing the code, which checked if the current and previous
> result of (expand-file-name ".." dir) were the same, to go into an
> infinite loop cycling between those two values...
The more I see such problems the more I think that such code should
check (> (length before) (length after)). At least, that should
*guarantee* termination, no matter how weird expand-file-name can behave.
Stefan