Description of problem: Pasting into a gnome terminal (and presumably any other terminal) running bash is broken. The pasted text is highlighted in a very ugly manner, but whatever. The problem is not the ugly highlighting, the problem is that the paste doesn't *work*. In particular, pasting a newline only causes silent failure, not an actual newline. Version-Release number of selected component (if applicable): readline-8.1-2.fc34.x86_64 bash-5.1.0-2.fc34.x86_64 How reproducible: 100% Steps to Reproduce: 1. Select a command from another source (like an email in your web browser) 2. Paste it into the terminal running bash with a middle-clock 3. See it not run Actual results: Ugly highligted paste shows in terminal, but doesn't actually do anything. Expected results: Non-ugly working command. Additional info: The thing can be worked around by never pasting newlines, and instead pasting just partial lines and doing the finalization by hand. Or better yet, just fix it, by not enabling 'enable-bracketed-paste' by default. Add set enable-bracketed-paste Off to the .inputrc fixes it. But it shouldn't have been broken in the first place.
IMO I am not Fedora readline maintainer but FYI: This is an upstream readline-8.1 change: https://lists.gnu.org/archive/html/bug-readline/2020-12/msg00000.html Fedora tries not to deviate from upstream: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects The change could be proposed upstream first but given it is an intentional change of the last release I doubt Chet Ramey would change that again. Personally I even prefer this change as one can edit the copy-pasted command(s) before executing them by pressing Enter. I find perfectly fine using your ~/.inputrc, personally I use GIT for $HOME with tons of config files changing various OS defaults.
So there are 2 separate issues: 1. When 'bracketed-paste-mode' is enabled, command pasted from browser/e-mail clients is not executed on paste. This seems to work as expected. User is required to press enter before executing pasted commands. See 'enable-bracketed-paste' section here[1]. For e.g. I tried below command: echo -e "Please enter your name: " read name echo "Nice to meet you $name" and it works as expected on pressing enter. Let me know if there is any command that doesn't work. 2. Pasted command is highlighted. There is a new feature called 'faces' in readline-8.1 that has this feature enabled with bracketed paste mode. It's mentioned in the readline-8.1 release notes[2]: """ The most visible new feature is the addition of `faces', which highlights the text between the point and mark (the region, so this is also called `active region'). This was added to show visibly the text inserted by bracketed paste, and also marks the text found by incremental and non-incremental history searches. Several additional commands set the mark to take advantage of this feature. Bracketed paste mode is supported in more places (e.g., in vi `overstrike' mode). Faces are currently tied to bracketed paste and are enabled and disabled along with bracketed paste mode. Bracketed paste mode is enabled by default; there is a configure-time option to make the default setting disabled. """ It seems there is no way to turn it off right now (without turning off bracketed paste). I will leave a note to Chet over e-mail if he wants to follow up on this bug in upstream. [1] https://www.gnu.org/software/bash/manual/html_node/Readline-Init-File-Syntax.html#Readline-Init-File-Syntax [2] https://lists.gnu.org/archive/html/bug-readline/2020-12/msg00000.html
Chet mentioned that it works as expected and there is a workaround available to change the default setting (by editing .inputrc file). Closing this as not a bug.
relevant upstream report: https://gitlab.gnome.org/GNOME/vte/-/issues/2500
I think the issue is that even if bracketed paste has existed for a while, it wasn't enabled by default in Bash, and most people had no awareness of it. Now that it's enabled by default, they are thrown off by a change in behaviour in something that's perceived to be very common ("it always worked this way"), without much in the way of an indication that something is different. Yes, the foreground and background colours are swapped, but it seems like that's not enough. Possibly because copy-pasting involves selecting text which usually swaps the colours, and even if that's supposed to only happen at the source of the copy-paste, the distinction is lost to users. Would it be possible for Bash to display something like a "Paste received; edit and confirm or abort" line before/after the edit area? The other option is to get the terminal emulator to show some sort of notification, but then that will need to happen in every terminal emulator implementation.
Chet plans to have an option to disable highlighting (faces) in next release. But bracketed paste will be kept on by default, and pasted text will be kept highlighted. I am not sure if this behavior should be worked around in terminal emulator, as it is new for users and it will take time for users to get used to it.
(In reply to Debarshi Ray from comment #5) > I think the issue is that even if bracketed paste has existed for a while, > it wasn't enabled by default in Bash, and most people had no awareness of > it. Now that it's enabled by default, they are thrown off by a change in > behaviour in something that's perceived to be very common ("it always worked > this way"), without much in the way of an indication that something is > different. > > Yes, the foreground and background colours are swapped, but it seems like > that's not enough. Possibly because copy-pasting involves selecting text > which usually swaps the colours, and even if that's supposed to only happen > at the source of the copy-paste, the distinction is lost to users. > > Would it be possible for Bash to display something like a "Paste received; > edit and confirm or abort" line before/after the edit area? It may help initially, but then users would want to disable this message later, which would require adding another configuration option. In any case, I don't want to change it on distro level. > > The other option is to get the terminal emulator to show some sort of > notification, but then that will need to happen in every terminal emulator > implementation.
(In reply to Siteshwar Vashisht from comment #6) > > I am not sure if this behavior should be worked around in terminal emulator, > as it is new for users and it will take time for users to get used to it. So to me personally, the first big annoyance was how it completely changed behavior and there's no explanation and it's very non-obvious. Other things than pasting highlight things too (searching etc), and it's really easy to just paste something in like you always did, and then go on and do something else, and nothing ever happens. And once I did figure things out, I've been trying to get used to it. It's been several weeks (and I've actively _avoided_ doing the "inputrc" thing in order to teach myself the new world order), and while I've grown to understand _why_ you'd want to have this as a kind of confirmation thing, I still haven't gotten used to it, and I still find it a bit annoying. And I think I've figured out why I find it so annoying: when I cut-and-paste things, I'm in "mouse mode". I'm not a gamer, I don't use the keyboard with one hand, and the mouse with another. I'm "either or". And the "use mouse to cut-and-paste, and then press enter to make it happen" continues to be really really really annoying even now that I know to do it and it should be almost natural. Because it's exactly that "it needs both keyboard and mouse". So after having used this now for a while, I still very much dislike it, but I think the objection has gone from "it's surprising and non-onvious new behavior" to "if you want confirmation, I really would want to do so with the mouse". Is Chet still at "case.edu"? I've emailed with him long long ago, but it must be a decade or more by now. Linus
(In reply to Linus Torvalds from comment #8) > (In reply to Siteshwar Vashisht from comment #6) > > > > I am not sure if this behavior should be worked around in terminal emulator, > > as it is new for users and it will take time for users to get used to it. > > So to me personally, the first big annoyance was how it completely changed > behavior and there's no explanation and it's very non-obvious. Other things > than pasting highlight things too (searching etc), and it's really easy to > just paste something in like you always did, and then go on and do something > else, and nothing ever happens. > > And once I did figure things out, I've been trying to get used to it. It's > been several weeks (and I've actively _avoided_ doing the "inputrc" thing in > order to teach myself the new world order), and while I've grown to > understand _why_ you'd want to have this as a kind of confirmation thing, I > still haven't gotten used to it, and I still find it a bit annoying. > > And I think I've figured out why I find it so annoying: when I cut-and-paste > things, I'm in "mouse mode". I'm not a gamer, I don't use the keyboard with > one hand, and the mouse with another. I'm "either or". > > And the "use mouse to cut-and-paste, and then press enter to make it happen" > continues to be really really really annoying even now that I know to do it > and it should be almost natural. Because it's exactly that "it needs both > keyboard and mouse". > > So after having used this now for a while, I still very much dislike it, but > I think the objection has gone from "it's surprising and non-onvious new > behavior" to "if you want confirmation, I really would want to do so with > the mouse". > > Is Chet still at "case.edu"? I've emailed with him long long ago, but it > must be a decade or more by now. I usually contact him over chet.ramey. Unfortunately he is not on Red Hat bugzilla, so I can't CC him here. Also, bug-bash[1] is still active for public discussions. [1] https://lists.gnu.org/archive/html/bug-bash/ > > Linus
*** Bug 1984512 has been marked as a duplicate of this bug. ***
*** Bug 1968143 has been marked as a duplicate of this bug. ***