GNU bug report logs - #26911
25.2; eshell "cd .." doesn't work correctly with TRAMP

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de, yegortimoshenko <at> gmail.com
Subject: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP
Date: Sat, 29 Aug 2020 09:31:22 +0300

> Cc: 26911 <at> debbugs.gnu.org, mattiase <at> acm.org, michael.albinus <at> gmx.de,
>  yegortimoshenko <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 28 Aug 2020 22:52:28 -0700
> 
> > That period after the colon following the drive letter shouldn't be
> > there.  As you may imagine, many Emacs commands are now broken because
> > of this.  This must be fixed ASAP.
> 
> I installed the attached patch to revert the recent expand-file-changes in the 
> DOS_NT case, which should fix the problem you mentioned.

Thanks, it does.  But it produces a different problem:

  (expand-file-name "." "c:/foo/bar/") => "c:/foo/bar

(note the absence of the trailing slash).

> This part of fileio.c is hard to follow because of the #ifdef DOS_NT and #ifdef 
> WINDOWSNT and #ifdef MSDOS and whatnot. How about if we move the 
> MS-Windows-specific code to a different source file instead of having that 
> forest of ifdefs in fileio.c? As things stand, it's hard to maintain the 
> mainline GNU code, because the way everything's arranged the Microsoft-specific 
> stuff significantly obfuscates everything else.

Sorry, I'm not interested in messing with expand-file-name, as the
gains are insignificant, if there are any, and the potential problems
that could cause are a legion.  I actually think that your latest set
of changes there was a mistake (for the same reasons), but as long as
you are prepared to fix the fallout, I won't actively object.

It took us a lot of blood, sweat, and tears to get to the point where
we are: that expand-file-name works correctly for all supported
systems (including DOS/Windows) and also the remote use case.  We all
know how one of the gazillion use cases of that function can be easily
broken by a seemingly innocent change in its complex code.  So I think
we should leave that function alone, and any problems with file names
(if they indeed are significant) should be fixed elsewhere.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.