unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 26911@debbugs.gnu.org, mattiase@acm.org, michael.albinus@gmx.de,
	yegortimoshenko@gmail.com
Subject: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP
Date: Sun, 30 Aug 2020 17:09:55 +0300	[thread overview]
Message-ID: <83eenoxm18.fsf@gnu.org> (raw)
In-Reply-To: <164450fe-7f86-e336-87d4-13c52e52c61c@cs.ucla.edu> (message from Paul Eggert on Sat, 29 Aug 2020 13:42:23 -0700)

> Cc: 26911@debbugs.gnu.org, mattiase@acm.org, michael.albinus@gmx.de,
>  yegortimoshenko@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 29 Aug 2020 13:42:23 -0700
> 
> It surely would be better to fix the bug on MS-Windows. A good way to start 
> doing that is to refactor the code a bit to avoid the tricky #ifdefs it 
> currently uses, as these #ifdefs make bugs like this painful to fix. I can draft 
> a patch along those lines if you like. I realize you're dubious about 
> refactoring and so wouldn't install the patch without checking with you.

It isn't right for us to make significant changes in expand-file-name,
let alone refactor it.  Its code is complex and full of subtle dark
corners, many of which are not well covered by our test suite.
Refactoring it into something more elegant is a large job -- for a
very small gain, since the function does its job 99.99% of the time.
We would be wasting our sparse resources if we do any serious changes
there, and will almost certainly introduce quite a few bugs on the
way.

It isn't worth it, definitely not in order to fix the couple of rare
bugs we are facing.

Instead, we should fix these particular bugs by localized changes
whose effect is limited to the specific situations we need to fix.

So with that in mind, let's please go back to the problems we have and
see how they can be fixed without unnecessary refactoring.

The original problem in this bug report was identified by Michael:

> In fileio.c, lines 1393-1394, the following loop
> 
> --8<---------------cut here---------------start------------->8---
> 	    while (o != target && (--o, !IS_DIRECTORY_SEP (*o)))
> 	      continue;
> --8<---------------cut here---------------end--------------->8---
> 
> replaces "/ssh:host:/bin/.." by "/ssh:host:". But it should be
> "/ssh:host:/".

Actually, 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.

In your log message you alluded to another use case, unrelated to
remote file names, but didn't provide any details.  Can you please
provide them now?  Is that other use case really similar to the one
which started this bug report (if not, no need to fix them both
together)?

The related bug#34834 is again about remote file names, but it's a
different situation.  AFAICT, it should also be easy to fix in a
localized manner.

Making such localized changes will allow us to be certain we don't
break any use cases we already support successfully.

Finally, I see no reason to require expand-file-name to preserve the
trailing slash -- we never required this until now, and AFAIK had no
problems with that.  If some specialized use case does need this, I'd
prefer to fix that only where and when it really matters.  For
example, if some Eshell command needs it, let's first consider fixing
that in Eshell.

In any case, the trailing slash issue is only tangentially related to
the bugs discussed here, so let's not mix these separate issues.

Thanks.





  reply	other threads:[~2020-08-30 14:09 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-13 16:15 bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP Yegor Timoshenko
2017-05-13 18:25 ` Michael Albinus
2017-05-13 18:30   ` Yegor Timoshenko
2017-05-15 15:53     ` Michael Albinus
2020-08-26 20:39 ` Paul Eggert
2020-08-27 11:46   ` Michael Albinus
2020-08-27 18:31 ` Mattias Engdegård
2020-08-27 18:38   ` Eli Zaretskii
2020-08-27 18:54     ` Stephen Berman
2020-08-27 21:53   ` Paul Eggert
2020-08-28  6:39     ` Eli Zaretskii
2020-08-28  7:01       ` Eli Zaretskii
2020-08-28 10:48         ` Eli Zaretskii
2020-08-29  5:52           ` Paul Eggert
2020-08-29  6:31             ` Eli Zaretskii
2020-08-29 16:46               ` Paul Eggert
2020-08-29 16:59                 ` Michael Albinus
2020-08-29 18:29                   ` Eli Zaretskii
2020-08-29 19:12                     ` Michael Albinus
2020-08-29 19:31                       ` Eli Zaretskii
2020-08-30  9:46                         ` Michael Albinus
2020-08-30 14:14                           ` Eli Zaretskii
2020-08-29 18:26                 ` Eli Zaretskii
2020-08-29 20:42                   ` Paul Eggert
2020-08-30 14:09                     ` Eli Zaretskii [this message]
2020-08-30 21:39                       ` Paul Eggert
2020-08-31 14:58                         ` Eli Zaretskii
2020-08-31 18:15                           ` Paul Eggert
2020-08-31 18:56                             ` Eli Zaretskii
2020-08-31 23:36                               ` Paul Eggert
2020-09-01  2:33                                 ` Eli Zaretskii
2020-09-03 17:27                           ` Eli Zaretskii
2020-09-03 17:42                             ` Michael Albinus
2020-09-04 11:55                             ` Michael Albinus
2020-09-04 12:25                               ` Eli Zaretskii
2020-09-04 13:53                                 ` Michael Albinus
2020-09-04 14:40                                   ` Eli Zaretskii
2020-09-04 15:20                                     ` Eli Zaretskii
2020-09-04 15:59                                       ` Michael Albinus
2020-09-04 17:42                                         ` Eli Zaretskii
2020-09-05  8:34                                           ` Michael Albinus
2020-09-05 11:18                                             ` Eli Zaretskii
2020-09-05 11:32                                               ` Eli Zaretskii
2020-09-05 15:57                                               ` Michael Albinus
2020-09-05 16:33                                                 ` Eli Zaretskii
2020-09-05 17:08                                                   ` Eli Zaretskii
2020-09-05 17:36                                                   ` Michael Albinus
2020-09-05 17:56                                                     ` Eli Zaretskii
2020-09-04 16:09                                     ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83eenoxm18.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=26911@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=mattiase@acm.org \
    --cc=michael.albinus@gmx.de \
    --cc=yegortimoshenko@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).