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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

内藤 祐一郎
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
[hidden email]




tramp.patch (521 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
内藤 祐一郎 <[hidden email]> 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
> [hidden email]

Best regards, Michael.


attachment0 (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

内藤 祐一郎
Thanks for the reply.

> 2020/07/28 3:01、Michael Albinus <[hidden email]>のメール:
>> 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
[hidden email]




Reply | Threaded
Open this post in threaded view
|

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

Michael Albinus
内藤 祐一郎 <[hidden email]> 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.