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

[Paul Eggert <eggert@cs.ucla.edu>]

On 8/31/20 7:58 AM, Eli Zaretskii wrote:

> expand-file-name deals only with the syntax of file names.

Yes, but it does so under constraints imposed by semantics. This is why 
expand-file-name can't simply remove *all* slashes from file names (which would 
be just a "syntax" thing, no? :-).

On GNU and other POSIXish systems, expand-file-names is entitled to do its 
syntactic manipulations only because because of the POSIX rules that "." means 
the working directory, leading "/" means the file name is absolute, trailing "/" 
means the file name is that of a directory, and so forth.

expand-file-name can simplify "/./" to "/", even though it cannot always 
simplify "/." to "" (and it cannot simply remove *all* slashes :-), because 
expand-file-name's syntactic manipulations simplify the file name in a safe way 
that does not change the file name's meaning. (This principle has one 
well-documented exception for symbolic links that do not point to sibling 
directories, but that does not overturn the principle elsewhere.)

> It is therefore perfectly valid for it to remove the trailing "/."
> without appending a slash.

Not at all. In many cases that would change the meaning of the file name, and 
expand-file-name is not supposed to do that. On GNU and POSIXish platforms it is 
valid to remove trailing "/." in some cases (e.g., "/foo//.") but it is 
definitely not valid to do it in all cases.

> It is not the job of expand-file-name to interpret file names.

That depends on what one means by "interpret". It is the job of expand-file-name 
to simplify file names under standard assumptions consistent with the underlying 
platform's behavior. If a "simplification" would disagree with the behavior of 
the underlying platform, that would cause needless confusion and 
expand-file-name should not do that.

> Lisp programs that need a directory's name to end in a slash should call
> file-name-as-directory, this is why we have that function.

That is a separate point, and is not directly relevant to whether 
expand-file-name should change a file name's meaning by removing slashes from it.

> If we insist on appending the slash in all cases

Nobody is insisting on that.

All I'm saying is that if the user has put a slash in a file name, 
expand-file-name should not remove the slash if the removal would change the 
file name's meaning. This is a simple principle that is easy to explain to 
users. No other principle would make nearly as much sense.

>>> 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.
> 
> You are talking about the code after your changes, whereas I (and
> Michael at the time he wrote that) were talking about the code before
> your changes: then the above snippet affected all platforms.

Feel free to alter the code to fix these bugs in a different way. However, I 
expect any such fix will be simpler if starts with the current code (which fixes 
the bugs on GNU and other POSIX hosts) instead of with the older code (which 
does not).