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

["内藤 祐一郎" <naito.yuichiro@gmail.com>]

Thanks for the reply.

> 2020/07/28 3:01、Michael Albinus <michael.albinus@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@gmail.com