Subject: bug#39399: closed (Re: bug#39399: tramp depends on unstable details of shell command line processing)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 28 Jul 2020 07:35:01 +0000

Your bug report

#39399: tramp depends on unstable details of shell command line processing

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
39399: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39399
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#39399: tramp depends on unstable details of shell command line processing
From: Michael Albinus <[email-masked]>
To: 内藤 祐一郎 <[email-masked]>
Cc: John F Carr <[email-masked]>, [email-masked]
Date: Tue, 28 Jul 2020 09:34:36 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

内藤 祐一郎 <[email-masked]> writes:

Hi,

>> Appended is a patch for Tramp 2.4.4. You might install it from GNU
>> ELPA. Please check, whether this works for you.
>
> The appended patch works for me.
> But I think just moving "set +o emacs +o vi” before “stty …” is more simple way.

Thanks for the feedback. In fact, the patch does exactly this: moving up
the "set +o emacs +o vi” command. The rest of the patch removes the
handling of "~/.editrc", which was added as first attempt to solve this
bug, and which isn't needed anymore.

@John, I've Cc'ed you that you can check whether the changed fix still
works for you.

I'm closing this bug, again. The patch has been committed to the
repositories. Tramp 2.4.4.1, planned to be released later this week on
GNU ELPA, will contain it.

Furthermore, this patch will also be in Emacs 27.2. For Emacs 27.1 it's
too late to commit.

> Yuichiro NAITO

Best regards, Michael.

Subject: tramp depends on unstable details of shell command line processing
From: John F Carr <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sun, 2 Feb 2020 21:28:40 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

I use emacs tramp mode for remote editing.  It stopped working on my FreeBSD systems when I upgraded to a development version.  The cause appears to be due to /bin/sh reprinting the entire line when a backspace is sent rather than sending only a backspace-space-backspace sequence.  The failure follows a change in the line editing library (shared with NetBSD) rather than the shell itself.

Environment is emacs 24.5 or 26.3 running on Mac OS Catalina.  The remote system is FreeBSD 13.0 development.  Tramp works with Linux or FreeBSD 12.1 as the remote system.

Here's what happens.

I load tramp and open a file like /ssh:user@host:/.  Emacs spawns ssh to connect.  The first thing tramp does is send

stty -inlcr -onlcr -echo kill '^U' erase '^H'

But this doesn't do much because the tty is in raw mode rather than cooked due to the shell's line editor.  So tramp falls back to a hack to detect echoed input.  It sends "_echo" followed by a string of backspace characters.  "_echo" is unlikely to appear in program output.

Here is the next command after the initial stty:

_echo^H^H^H^H^Hstty icanon erase ^H cols 32767_echo^H^H^H^H^H

The groups of 5 ^H represent 5 backspace characters and the lone ^H in the middle is a two character sequence for stty.

The terminal output from a 12.1 system is

_echo^H ^H^H ^H^H ^H^H ^H^H ^Hstty icanon erase ^H cols 32767_echo^H ^H^H ^H^H ^H^H ^H^H ^H
#$ 

where again the middle ^H is a two character sequence and the others are backspace characters. There is a carriage return between the two lines.  "#$ " is the shell prompt set by tramp.

The terminal output from a FreeBSD 13.0 development branch system is

_echo
#$ _ech ^H
#$ _ec ^H
#$ _e ^H
#$ _ ^H
#$  ^Hstty icanon erase ^H cols 32767_echo
#$ stty icanon erase ^H cols 32767_ech ^H
#$ stty icanon erase ^H cols 32767_ec ^H
#$ stty icanon erase ^H cols 32767_e ^H
#$ stty icanon erase ^H cols 32767_ ^H
#$ stty icanon erase ^H cols 32767 ^H
#$ 

with carriage returns between lines.  This does not make sense to emacs, which hangs waiting for something it recognizes.  I can recover by hitting control-G which aborts the tramp connection.

This issue is also reported to FreeBSD at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243807.