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 21:26:51 +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: Sat, 29 Aug 2020 09:46:29 -0700
> 
> >> 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).
> 
> That's what Emacs 27 does on MS-Windows, no? So it's not a regression, and the 
> problem can be fixed at the convenience of whoever's interested in hacking on 
> the MS-Windows side of the code.

It's a regression wrt behavior on Posix platforms: it fails one of the
tests in fileio-tests.el:

  Test fileio-tests--HOME-trailing-slash condition:
      (ert-test-failed
       ((should
	 (equal
	  (expand-file-name "~")
	  (expand-file-name home)))
	:form
	(equal "c:/a/b/c" "c:/a/b/c/")
	:value nil :explanation
	(arrays-of-different-length 8 9 "c:/a/b/c" "c:/a/b/c/" first-mismatch-at 8)))
     FAILED   1/12  fileio-tests--HOME-trailing-slash (0.000000 sec)

> Another way to put it is that Bug#26911 is now fixed for GNU and POSIX, but not 
> for MS-Windows. My earlier changes attempted to fix it for all platforms, but 
> this had undesirable side-effects in MS-Windows so I withdrew the MS-Windows 
> part of the changes. I have therefore reopened Bug#26911 since I assume it's 
> still present on MS-Windows.

If that is the case, I prefer that we revert all the changes made
recently to fix bug#26911, and leave that bug open, until a fix is
available that works on all platforms.

> > I'm not interested in messing with expand-file-name
> 
> That's understandable as expand-file-name is quite a mess internally. But if 
> you're not interested in any attempt to clean up the mess, I guess I should 
> refrain from giving it a shot.

Fine with me, then let's revert the recent changes and go back to what
we had before.

Thanks for trying to fix that.

Previous Next

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