bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP

[Paul Eggert]

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.