New versions of Bash (and readline) default to special handling of pasting into the shell (or other programs)

June 4, 2021

Our standard habit on our OpenBSD machines is to use their packaged version of Bash as the root shell, instead of the default of OpenBSD's version of ksh. When I set up an OpenBSD 6.9 machine recently and started to paste in install steps from our standard instructions, an odd thing happened: the line I'd just pasted in was highlighted in reverse video and Bash just sat there, instead of doing anything. After some fiddling around, I discovered that I had to hit Return in order get things to go (and at that point Bash would act on all of the input without further prompts, even if I'd pasted in multiple lines).

People who are more familiar with Bash and readline than I was already know what this is; this is the Bash readline setting of enable-bracketed-paste. OpenBSD 6.9 is the first Unix I've encountered where this was turned on by default. This isn't because OpenBSD did anything special; instead, it's because OpenBSD 6.9 is the first Unix I've used that has Bash 5.1. As mentioned in the detailed Bash list of changes, bracketed paste mode was enabled by default starting in bash-5.1-alpha. The reverse video behavior of it is also new there; in 5.0 and before, nothing special shows in bracketed paste mode to signal that something unusual is going on.

Bash 5.1 will be rolling out over time to more Unixes, so I suspect that more people will be running into this behavior unless their particular Unix opts to disable it in one way or another. If I had updated to Fedora 34 by now, it's possible I'd have already encountered this (I believe that Fedora 34 has Bash 5.1, but I don't know how Fedora opted to set bracketed paste).

This change to the default of bracketed paste is also in GNU Readline 8.1 (according to its CHANGES). However, Readline has a configuration time option that can change this, so different Unixes may opt to build Readline differently. On a Unix with Readline 8.1+ and bracketed paste enabled by default, I believe that all programs using GNU Readline will automatically have this behavior.

(This directly affects me because these days I build my alternate shell using GNU Readline. If I do nothing, it will someday inherit this behavior on new versions of Fedora and Ubuntu.)

If you decide that you don't want bracketed paste mode, the safest change is to set this in either your $HOME/.inputrc or globally in /etc/inputrc. You would do this with:

set enable-bracketed-paste off

This will (or should) cover Bash and anything else that starts using Readline 8.1 on a Unix that builds 8.1 with this enabled. Adding this to your .inputrc today is harmless if you have Readline 7.0 and Bash 4.4 or later (the versions where this setting was introduced).

If you just want to turn this off only in Bash (at least for now), I think that you want to set up a $HOME/.bashrc that has in it:

bind 'set enable-bracketed-paste off'

You can set this in your .profile, but then it won't be turned on in subshells.

How to set this bind up globally for Bash depends on how your Unix's version of Bash was built and may not be possible. Ubuntu builds Bash so that there's a global /etc/bash.bashrc you can put this bind into, but Fedora and OpenBSD don't. Fedora provides a starting .bashrc for new accounts that source /etc/bashrc, so you can put the bind there and probably get most people. Since Bash is an add-on in OpenBSD, it has nothing like this and people are on their own to disable it one by one.

Comments on this page:

From at 2021-06-04 02:37:02:

the line I'd just pasted in was highlighted in reverse video and Bash just sat there, instead of doing anything

This isn't particularly new in general; Zsh users have been familiar with this exact feature for several years.

Personally, I like it. It lets me know exactly what I pasted, even if it does cost me an extra Enter keypress. (As long as it comes with the visual indication, of course... tried it in 5.0 which didn't have the reverse yet, and it was very confusing then.)

It might even count as a security feature, too, like the example websites with curl | <font size=0>malicious</font> bash that made the rounds last year.

However, I still turn it off for the Python interpreter specifically, because for some reason this makes its handling of multi-line pastes worse than before (the direct mode allowed you to paste whole functions, bracketed paste somehow doesn't). So I have this in my `~/.inputrc`:

$if Python
set enable-bracketed-paste off

(The $PYTHONSTARTUP equivalent would be readline.parse_and_bind(..).)

And in the same vein, you can do

$if Bash
set enable-bracketed-paste off

to turn it off only in Bash but always in Bash – whether for yourself in ~/.inputrc or for everyone in /etc/inputrc.

By seth at 2021-06-04 10:34:47:

Can confirm it's on by default in F34.

I've found it annoying, but without knowing what it was. Now I'm not sure whether to keep or disable it.

By Opk at 2021-06-05 18:21:14:

At least for Zsh, with which I have some involvement, a large part of the motivation was security. It is possible for a website to subvert the browser into copying quite different text to what a user thinks they've copied. Any change in default behaviour tends to be controversial and that was certainly the case here. Temporary highlighting of the pasted text was an idea that came out of that discussion and it is interesting that bash has copied that. I'm not aware of any other text editor or application that highlights pasted text so there was no prior inspiration for it but I actually quite like that feature in general.

The bracketed paste feature also has other useful benefits such as making it possible to manipulate pasted text (such as quoting it) with a custom key prefix.

Written on 04 June 2021.
« Fedora co-mingles its source packages with Red Hat Enterprise Linux
HTTP/3 needs us (and other people) to make firewall changes »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jun 4 00:04:51 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.