pasting into bash changed recently

Normally when you grab text in one xterm, until the right border of the xterm, and then paste that into another xterm, it will immediately execute. That is, a line feed is sent to the shell there, at the end of the text.
This used to work no matter which sh, csh or bash is running.

It recently has changed - but only for bash. Now when it receives the paste, the pasted text gets highlighted, the cursor moves to the beginning of a new line, but it does not execute, until one presses enter. Even when pasting two or more lines, they don't execute.

What I find in the logs is only this:
pkg[26573]: bash upgraded: 5.1.4 -> 5.1.4_1
and this should not be a functional change.

Anybody else observing this?
 
I can't answer your question since I don't use bash as my default shell but it can be disabled with:
Code:
bind 'set enable-bracketed-paste off'
 
  • Thanks
Reactions: PMc
Great, thank You spectrum48 for the proper keyword & clarification!

It appears this is considered a security feature(*), and therefore cannot simply be switched off where it concerns: in the desktop. i.e. in the xterm. Instead it has to be switched off in each and every one of myriads of jails, guests, remote servers etc.etc. individually - and then have this crap again and again whenever deploying a new instance.
People seem to like this "feature", but I am not really amused.

Or, to make it stick:
echo "set enable-bracketed-paste off" >> ~/.inputrc

Yes, really? ;) No. Not with me, at least. With a deploy chain, the cheapest approach seems to be this one:
Code:
diff --git a/devel/readline/Makefile b/devel/readline/Makefile
index 709d35a01232..15fb80ff4fa3 100644
--- a/devel/readline/Makefile
+++ b/devel/readline/Makefile
@@ -18,6 +18,7 @@ USES=         cpe
 
 GNU_CONFIGURE= yes
 USE_LDCONFIG=  yes
+CONFIGURE_ARGS+=--disable-bracketed-paste-default
 
 INFO=          history readline rluserman
 PLIST_SUB=     PORTVERSION=${PORTVERSION:R}

Alright, this feature comes from the GNU/linux toolset, and there people may have an issue with pasting from the browser, from unknown sources. But here we are running servers, and doing systems management. You don't need focus to paste a command into a couple xterms, but you have to focus every one of them to press enter afterwards. I'd say, the above patch should be a port option.

(*) in the beginning we were fighting bugs. now we are fighting features.
 
Bracketed paste is not something I'd consider a security feature; it's just a feature. See the discussion at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787628 for example.

Ultimately, the setting just takes advantage of a feature in XTerm (and some other terminal emulators supporting it such as URxvt) known as Bracketed Paste Mode. When Bracketed Paste Mode is enabled, the terminal emulator will send ESC [ 2 0 0 ~, then the text, then ESC [ 2 0 1 ~, informing an application that the text sent to the application between those two control sequences is pasted text, not a sequence of key presses for the application to interpret. Libedit/Editline as used by sh(1), however, currently does not seem to interpret the "bracketed" control sequences sent by the terminal emulator, so Readline is probably the best place to enable the feature since applications using Readline may be the only applications that will understand those special control sequences. That said, there's nothing stopping you from using printf '\033[?2004h' in sh(1), but pasting any text (even text with no control sequences) will result in unexpected output due to the control sequences used to delimit the start and end of the pasted text.
 
I find it useful because I sometimes need to paste a command and modify it before committing it. This feature avoids me to send it unmodified to the shell if I mistakenly copy the EOL character too.
 
Back
Top