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
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).
This bug report was last modified 4 years and 256 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.