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: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Sun, 30 Aug 2020 14:39:28 -0700

On 8/30/20 7:09 AM, Eli Zaretskii wrote:

> you alluded to another use case, unrelated to
> remote file names, but didn't provide any details.
Here's an example. On RHEL 7.8 (file-symlink-p "/bin/.") returned "usr/bin" 
which was a bug since "/bin/." is not (and cannot possibly be) a symbolic link. 
This bug occurred because file-symlink-p calls expand-file-name which 
incorrectly stripped trailing "/." from the file name before checking the file's 
status. This sort of behavior broke code in startup.el that used file-attributes 
(which had the same bug) to compare $PWD to the working directory's name, which 
is how I ran into the bug again. (I vaguely recall running into this bug earlier 
but lacked time/energy then to track it down and fix it.)

> Is that other use case really similar to the one
> which started this bug report

I expect they're related if we look at the mess inside file-attributes. They may 
not appear to be similar to users who don't know how Emacs is implemented.

> I see no reason to require expand-file-name to preserve the
> trailing slash

It's required because trailing slash affects how file names are interpreted on 
GNU and other POSIXish platforms. Emacs should not second-guess GNU and POSIX on 
this: it should interpret file names like the underlying platforms do, as 
anything else would be unnecessarily confusing.

> IMO the problem is immediately following the above snippet:
> 
> 	    /* Keep initial / only if this is the whole name.  */
> 	    if (o == target && IS_ANY_SEP (*o) && p[3] == 0)
> 	      ++o;
> 
> This is very easy to fix without affecting any other uses of the
> function: we should consider one other case in addition to "only if /
> is the whole name" -- the case where this fails to DTRT with remote
> directories.

Such a fix should be no problem for the GNU/POSIXish side, as that snippet is in 
the DOS_NT code and any fixes there should affect only MS-Windows and DOS. I 
don't know what a "remote directory" is in that context, though, so I can't give 
specific advice.

> Its code is complex and full of subtle dark
> corners, many of which are not well covered by our test suite.

expand-file-name is more complex than it needs to be, and its dark corners would 
be less dark if we cleaned it up a bit. In refactoring I would not attempt 
elegance, only understandability. Right now the code is needlessly hard to 
understand, and that makes it hard to fix - something I encountered while trying 
to fix some of the abovementioned bugs.

Previous Next

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