GNU bug report logs - #39399
tramp depends on unstable details of shell command line processing

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39399 in the body.
You can then email your comments to 39399 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John F Carr <jfc <at> mit.edu>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: tramp depends on unstable details of shell command line processing
Date: Sun, 2 Feb 2020 21:28:40 +0000

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 <at> 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.

Message #8 received at 39399 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: John F Carr <jfc <at> mit.edu>
Cc: 39399 <at> debbugs.gnu.org
Subject: Re: bug#39399: tramp depends on unstable details of shell command
 line processing
Date: Mon, 03 Feb 2020 09:58:26 +0100

John F Carr <jfc <at> mit.edu> writes:

Hi John,

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

Thanks a lot for your report! Since I'm not running FreeBSD anywhere, I
count on your support fixing the problem :-)

> Here's what happens.
>
> I load tramp and open a file like /ssh:user <at> 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.

Well, and this works for years.

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

IIUC the discussion in that bug, it is due to the changed libedit of
FreeBSD 13. Hmm, don't know this beast. But wouldn't it help, if Tramps
sends initially "stty cooked"?

Best regards, Michael.

Message #11 received at 39399 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: John F Carr <jfc <at> mit.edu>
Cc: 39399 <at> debbugs.gnu.org
Subject: Re: bug#39399: tramp depends on unstable details of shell command
 line processing
Date: Tue, 04 Feb 2020 09:34:26 +0100

[Message part 1 (text/plain, inline)]

Michael Albinus <michael.albinus <at> gmx.de> writes:

Hi John,

>> 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.
>
> IIUC the discussion in that bug, it is due to the changed libedit of
> FreeBSD 13. Hmm, don't know this beast. But wouldn't it help, if Tramps
> sends initially "stty cooked"?

I've digged further. Likely, the problem can be avoided if we disable
command line editing of the shell. Tramp does it already if the remote
shell is zsh; I've added a similar parameter to the bash invocation. For
other shells, like ksh, I haven't found a simple parameter.

For that class of shells, I've added code which installs a temporary
~/.editrc file, containing the line 'edit off'.

Could you please migrate to Tramp 2.4.3.1 from GNU ELPA? On top of this,
install the appended patch.

And pls report, whether it works for you.

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

Message #16 received at 39399 <at> debbugs.gnu.org (full text, mbox):

From: John F Carr <jfc <at> mit.edu>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: "39399 <at> debbugs.gnu.org" <39399 <at> debbugs.gnu.org>
Subject: Re: bug#39399: tramp depends on unstable details of shell command
 line processing
Date: Wed, 5 Feb 2020 23:42:00 +0000

On Feb 4, 2020, at 03:34 , Michael Albinus <michael.albinus <at> gmx.de> wrote:
> 
> Michael Albinus <michael.albinus <at> gmx.de> writes:
> 
> Hi John,
> 
>>> 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.
>> 
>> IIUC the discussion in that bug, it is due to the changed libedit of
>> FreeBSD 13. Hmm, don't know this beast. But wouldn't it help, if Tramps
>> sends initially "stty cooked"?
> 
> I've digged further. Likely, the problem can be avoided if we disable
> command line editing of the shell. Tramp does it already if the remote
> shell is zsh; I've added a similar parameter to the bash invocation. For
> other shells, like ksh, I haven't found a simple parameter.
> 
> For that class of shells, I've added code which installs a temporary
> ~/.editrc file, containing the line 'edit off'.
> 
> Could you please migrate to Tramp 2.4.3.1 from GNU ELPA? On top of this,
> install the appended patch.
> 
> And pls report, whether it works for you.
> 
> Best regards, Michael.
> 
> <Mail Attachment>

Your change applied to tramp 2.4.3 from ELPA works.

Message #21 received at 39399-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: John F Carr <jfc <at> mit.edu>
Cc: "39399 <at> debbugs.gnu.org" <39399-done <at> debbugs.gnu.org>
Subject: Re: bug#39399: tramp depends on unstable details of shell command
 line processing
Date: Thu, 06 Feb 2020 10:13:47 +0100

Version: 27.2

John F Carr <jfc <at> mit.edu> writes:

Hi John,

>> I've digged further. Likely, the problem can be avoided if we disable
>> command line editing of the shell. Tramp does it already if the remote
>> shell is zsh; I've added a similar parameter to the bash invocation. For
>> other shells, like ksh, I haven't found a simple parameter.
>>
>> For that class of shells, I've added code which installs a temporary
>> ~/.editrc file, containing the line 'edit off'.
>>
>> Could you please migrate to Tramp 2.4.3.1 from GNU ELPA? On top of this,
>> install the appended patch.
>>
>> And pls report, whether it works for you.
>
> Your change applied to tramp 2.4.3 from ELPA works.

Thanks for the feedback. Since I have no *BSD machine, I couldn't test
the patch; it was rather a shot into the dark.

I've pushed the patch, slightly modified, to the Emacs and Tramp
repositories. It won't appear with Emacs 27.1, because it is too late to
commit such serious changes so close to its release; but I will merge it
into the emacs-27 codebase after Emacs 27.1 has been released.

The next GNU ELPA Tramp release, 2.4.3.2, will carry this patch. It will
appear in a couple of weeks.

Best regards, Michael.

Message #30 received at 39399 <at> debbugs.gnu.org (full text, mbox):

From: 内藤 祐一郎 <naito.yuichiro <at> gmail.com>
To: 39399 <at> debbugs.gnu.org
Subject: Re: tramp depends on unstable details of shell command line processing
Date: Mon, 27 Jul 2020 13:12:21 +0900

[Message part 1 (text/plain, inline)]

Hi.

I could find a another way to solve this problem that avoids changing ~/.editrc and it's more simple.
See my patch attached on this mail.

This problem happens on the latest libedit and FreeBSD sh uses Emacs edit mode by default.

If libedit runs on edit mode, libedit rewrites line by each control character.
On '^H', libedit sends line feed and write characters on the line that is held in the internal screen buffer of libedit.

If edit mode turns off, line edit works on terminal that is as same as previous behavior.

Shell command `set +E` escapes from edit mode in spite of libedit has two edit mode (Emacs and Vi). `set +E` disables both of them.

Although libedit has been developed and used by NetBSD, NetBSD doesn’t have this problem.
Because NetBSD sh doesn't use edit mode by default.

I could confirm my patch solves this problem on emacs-26.3.
And also works to FreeBSD current & OpenBSD current & RedHat 7.8.

—
Yuichiro NAITO
naito.yuichiro <at> gmail.com

[tramp.patch (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

Message #33 received at 39399 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: 内藤 祐一郎 <naito.yuichiro <at> gmail.com>
Cc: 39399 <at> debbugs.gnu.org
Subject: Re: bug#39399: tramp depends on unstable details of shell command
 line processing
Date: Mon, 27 Jul 2020 20:01:57 +0200

[Message part 1 (text/plain, inline)]

内藤 祐一郎 <naito.yuichiro <at> gmail.com> writes:

> Hi.

Hi,

> I could find a another way to solve this problem that avoids changing
> ~/.editrc and it's more simple.
> See my patch attached on this mail.
>
> This problem happens on the latest libedit and FreeBSD sh uses Emacs
> edit mode by default.
>
> If libedit runs on edit mode, libedit rewrites line by each control character.
> On '^H', libedit sends line feed and write characters on the line that
> is held in the internal screen buffer of libedit.
>
> If edit mode turns off, line edit works on terminal that is as same as
> previous behavior.
>
> Shell command `set +E` escapes from edit mode in spite of libedit has
> two edit mode (Emacs and Vi). `set +E` disables both of them.
>
> Although libedit has been developed and used by NetBSD, NetBSD doesn’t
> have this problem.
> Because NetBSD sh doesn't use edit mode by default.

Thanks for the report. However, your patch is not applicable in general,
because the "+E" option is not POSIX conform, and it isn't supported by
all shells. I thought already about this when I was fixing bug#39399.

But wait - "set +o emacs +o vi" might give the same effect, and it is
much more supported by shells. And reading the sources, Tramp calls it
already (might have been added by Kai, many years ago). Maybe it is
sufficient to move it earlier in the initialization machinery?

Appended is a patch for Tramp 2.4.4. You might install it from GNU
ELPA. Please check, whether this works for you.

> Yuichiro NAITO
> naito.yuichiro <at> gmail.com

Best regards, Michael.

[Message part 2 (text/x-patch, attachment)]

Message #36 received at 39399 <at> debbugs.gnu.org (full text, mbox):

From: 内藤 祐一郎 <naito.yuichiro <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 39399 <at> debbugs.gnu.org
Subject: Re: bug#39399: tramp depends on unstable details of shell command
 line processing
Date: Tue, 28 Jul 2020 11:51:42 +0900

Thanks for the reply.

> 2020/07/28 3:01、Michael Albinus <michael.albinus <at> gmx.de>のメール:
>> I could find a another way to solve this problem that avoids changing
>> ~/.editrc and it's more simple.
>> See my patch attached on this mail.
>> 
>> This problem happens on the latest libedit and FreeBSD sh uses Emacs
>> edit mode by default.
>> 
>> If libedit runs on edit mode, libedit rewrites line by each control character.
>> On '^H', libedit sends line feed and write characters on the line that
>> is held in the internal screen buffer of libedit.
>> 
>> If edit mode turns off, line edit works on terminal that is as same as
>> previous behavior.
>> 
>> Shell command `set +E` escapes from edit mode in spite of libedit has
>> two edit mode (Emacs and Vi). `set +E` disables both of them.
>> 
>> Although libedit has been developed and used by NetBSD, NetBSD doesn’t
>> have this problem.
>> Because NetBSD sh doesn't use edit mode by default.
> 
> Thanks for the report. However, your patch is not applicable in general,
> because the "+E" option is not POSIX conform, and it isn't supported by
> all shells. I thought already about this when I was fixing bug#39399.
> 
> But wait - "set +o emacs +o vi" might give the same effect, and it is
> much more supported by shells. And reading the sources, Tramp calls it
> already (might have been added by Kai, many years ago). Maybe it is
> sufficient to move it earlier in the initialization machinery?

Exactly yes it is!
“ set +o emacs +o vi” works as same as “set +E” on FreeBSD sh.
Tramp-mode hung before it, so it was not executed.

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

—
Yuichiro NAITO
naito.yuichiro <at> gmail.com

Message #41 received at 39399-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: 内藤 祐一郎 <naito.yuichiro <at> gmail.com>
Cc: John F Carr <jfc <at> mit.edu>, 39399-done <at> debbugs.gnu.org
Subject: Re: bug#39399: tramp depends on unstable details of shell command
 line processing
Date: Tue, 28 Jul 2020 09:34:36 +0200

内藤 祐一郎 <naito.yuichiro <at> gmail.com> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.