GNU bug report logs - #28139
25.2; TRAMP vs bash 4.4 / readline 7.0 "bracketed paste" mode

Previous Next

Package: emacs;

Reported by: Daniel Pittman <slippycheeze <at> google.com>

Date: Fri, 18 Aug 2017 15:34:01 UTC

Severity: normal

Found in version 25.2

Fixed in version 26.1

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Daniel Pittman <slippycheeze <at> google.com>
To: 28139 <at> debbugs.gnu.org
Subject: bug#28139: 25.2; TRAMP vs bash 4.4 / readline 7.0 "bracketed paste" mode
Date: Mon, 21 Aug 2017 11:19:31 -0400
[Message part 1 (text/plain, inline)]
On Sat, Aug 19, 2017 at 1:59 PM, Michael Albinus <michael.albinus <at> gmx.de>
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.
[Message part 2 (text/html, inline)]

This bug report was last modified 7 years and 283 days ago.

Previous Next


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