Subject: Re: bug#28139: 25.2; TRAMP vs bash 4.4 / readline 7.0 "bracketed paste" mode

From: Daniel Pittman <[email-masked]>
Date: Mon, 21 Aug 2017 11:19:31 -0400

On Sat, Aug 19, 2017 at 1:59 PM, Michael Albinus <[email-masked]>
wrote:

> > After upgrading a remote system to a version of GNU/Linux that
> > includes bash
> > 4.4 (from Debian/testing), with the readline option `set
> > enable-bracketed-paste on` in /etc/inputrc, and no personal inputrc,
> > tramp breaks.
>
> Many different shells are busy to break Tramp.
>

Believe me, I know the pain.  This isn't my first time poking into the
internals of how TRAMP hits remote shells.

> > Passing the `--noediting` option to the remote shell command resolves
> > the problem, by disabling readline entirely, but it should also be
> > possible to augment the
> > `tramp-open-connection-setup-interactive-shell` to issue,
> > unconditionally, the command:
> >
> >     bind 'set enable-bracketed-paste off'
>
> Does it help to add the following line into your remote ~/.bashrc:
>
> [ $TERM = "dumb" ] && bind 'set enable-bracketed-paste off'
>

Alas, no, and the bash(1) man page "INVOCATION" section makes it clear why:

    Since a shell invoked as sh does not attempt to read and
    execute commands from any other startup files,
    the --rcfile option has no effect.

Interactive testing confirms this: if I invoke the shell the as TRAMP does,
with:

env ENV='' HISTFILE='' HISTFILESIZE=0 HISTSIZE=0 PROMPT_COMMAND=''
PS1=\#\$\  PS2='' PS3='' /bin/sh

...then strace confirms that no init files are read, other than /etc/inputrc

So, it's not possible to work around this issue without injecting
additional code into the shell setup process, using `/bin/sh --noediting`,
or using an interactive shell and adding that to the .profile or equivalent.

note: --noediting has been present since bash 2.0 according to their
changelog, so it may be reasonable to add by default to the non-interactive
shell invocations.

Ultimately, though, perhaps adding the ability to run additional commands
during the interactive shell setup process and/or consuming any CSI
sequences prior to matching, would be a more future-proof solution to this.