Why Bash and GNU Readline's "bracketed paste" mode is not for us

July 10, 2021

Last month, we discovered that recent versions of Bash and GNU Readline now default to special handling of pasting into them. This is called "bracketed paste" mode; it requires you to explicitly hit Return in order to have the pasted text accepted and allows you to edit the paste before then. Locally, we have decided to turn this off for the root account, and I've also turned it off for my own account. We have pragmatic reasons for our collective decision, and I also have a broad general reason for my own account.

Our pragmatic reason is that we are almost always pasting from our own instructions, which we obviously trust. In addition, we do this sort of pasting quite a bit. Since our own source text is trusted, an extra step to accept them is both annoying and almost certainly ineffective at avoiding mistakes. Since we know the source is trusted, we're extremely unlikely to pause, look at what we're about to hit Return on, and realize we've pasted the wrong thing, especially since we do this all the time.

(People are extremely bad at spotting the one in a thousand exception to routine processes.)

My broader personal reason is that bracketed paste quietly clashes with the xterm model of fast cut and paste. Xterm and things that imitate it are specifically set up so that you can cut and paste entirely from the mouse; you use the left and perhaps right mouse buttons to make your selection and then the middle mouse button to paste it. Bracketed paste doesn't just require an extra step, it requires you to use the keyboard. On top of that, right-handed mouse users with normal keyboards either have to move their right hand from the mouse to the Return key or reach over with their left hand to hit Return.

Bracketed paste probably looks better to laptop users (where the 'mouse' is below the keyboard) and to people who use Copy and Paste through the keyboard with Ctrl-C and Ctrl-V. But for xterm users who trust the source they're pasting from, I suspect that the inconveniences outweigh the occasional advantage of being able to edit what you're pasting to alter it a bit before it takes effect.

(The traditional way to be able to edit what you're pasting in xterm is to not select and paste the trailing newline. However, this usually requires you to use a slower selection method than just triple-clicking the source line.)

PS: What I would actually like is a way to invoke bracketed paste in xterm when pasting, for example with shift plus the middle mouse button. This would improve the convenience of pasting things that I want to edit after pasting, because I could freely select things with newlines but still modify them before they act.

Comments on this page:

By Andy Balholm at 2021-07-12 11:34:37:

In my experience, the main advantage of bracketed paste is when the contents of the clipboard is not what I think it is. So I can see the mistake before it's actually executed.

Written on 10 July 2021.
« University computer accounts are often surprisingly complicated
Understanding something about udev's normal network device names on Linux »

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

Last modified: Sat Jul 10 23:44:32 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.