12

A couple of months ago, a system update caused my shell to no longer interpret trailing newlines as an enter when pasting a command into the terminal. For example, if I write ls at my prompt and then use my mouse to select the ls until the end of the line, I expect that I can then middle-click paste into a shell and have the ls command executed. This is standard behavior which I have been using for years.

However, my system no longer does that. I can paste the ls, and I can see the newline was also pasted because my cursor moves to the next line, but despite this, the command isn't executed until I press enter (I am putting this in a spoiler because it is an animated gif and can be distracting):

animated gif showing the effect described

In the animation above, you can see me selecting a line with ls already written, then clearing the ls and middle-click pasting. Note how the cursor moves to the next line, but the ls command isn't executed at that point, but only after I hit my enter key.

The really strange thing, for me, is that this isn't an issue with my terminal emulator (terminator). The very same terminal will interpret the newline as expected if I ssh into a different machine (but not if I ssh into localhost). So it has to be some sort of setting in my local shell.

Also, there is one context where it does work as expected: the read builtin. Here, if I select a line including the trailing newline, I can paste it into a waiting read prompt and the trailing newline is taken as the EOL character, making read return. So why doesn't it work outside that specific context?

All of this is on an Arch Linux system, using GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu) in emacs mode. To make matters even more confusing, I have this issue when using bash, zsh or fish, but not when using ksh, dash, tcsh or csh. In the latter four shells, I have my desired behavior and the pasted line is immediately executed. Could this be related to readline?

How can I get my desired behavior back and have any newlines pasted into my shell be interpreted?

8
  • Happens with Cygwin bash too. Line editing is vi mode. Relatively recently. Looking forward to an answer here, but I would suggest that it is indeed a readline change Feb 5, 2022 at 14:07
  • 1
    @Quasímodo not really, no. I want the behavior that the other question is trying to avoid. Sure, you can maybe guess that setting the same setting to off (which isn't mentioned there) might help, but the questions are diametrically opposed with one asking "how can I NOT do foo" and the other asking "how can I DO foo?". Also, the dupe does not address what changed which roaima explains nicely.
    – terdon
    Feb 5, 2022 at 16:01
  • 3
    @terdon (with your regular - emphasis on "regular" - user hat still on you) - this is something I'd STRONGLY recommend against doing. The one time that this will prevent your from accidentally running a broken/dangerous command will mean that all the times you were mildly inconvenienced by having to press enter will be paid over.
    – muru
    Feb 6, 2022 at 6:32
  • 3
    I think @muru's point is worth emphasizing; I use the command line a lot, including copy/pasting text (which may be commands). Newlines included in the paste would often run a command before I had the chance to finetune it, and an incorrect paste could really mess things up. This has caused actual damage for me more than once. It took a bit of effort to get used to the new behaviour, but now I much prefer it.
    – marcelm
    Feb 6, 2022 at 11:16
  • 2
    @muru I would rather risk the malicious command. I very regularly need to copy/paste commands from my Readme files to reproduce things, and very often need to paste multiple commands that need to run sequentially, and having to switch from "mouse mode" to "keyboard mode" is incredibly annoying. On the other hand, I very rarely copy/paste commands from the internet so the chances of my having a malicious command in my clipboard are minimal. The annoyance far outweighs the risk for me. I check my commands before pasting.
    – terdon
    Feb 6, 2022 at 11:18

1 Answer 1

15

The behaviour change is captured in this "Not a bug" report with RedHat https://bugzilla.redhat.com/show_bug.cgi?id=1954366, which references the readline setting enable-bracketed-paste:

Add set enable-bracketed-paste Off to the .inputrc fixes it. But it shouldn't have been broken in the first place.

Indeed, adding this setting to ~/.inputrc resolves the issue: pasting an embedded newline executes the pasted command once more.

References

Please note that a number of experienced users both here and elsewhere strongly warn users against this. For example, @muru writes in a comment that, "this is something I'd STRONGLY recommend against doing. The one time that this will prevent you from accidentally running a broken/dangerous command will mean that all the times you were mildly inconvenienced by having to press enter will be paid over."

7
  • 2
    YESH! Thank you so much, this has been driving me up the wall for a while now! I guess I now need a follow-up question to understand why this affected only that specific set of shells. Presumably, these are the shells that read the ~/.inputrc file or that use readline or something.
    – terdon
    Feb 5, 2022 at 14:16
  • Allegedly enabled by default from bash version 5.1 but I'm finding it enabled in 4.4.12(3) Feb 5, 2022 at 14:17
  • Thank you for the solution! Please add to your answer that one needs to start a new bash session for this change to take effect. Pasting this into existing bash prompt doesn't change anything. Thank you!
    – stason
    Apr 1, 2022 at 2:37
  • @stason I'm pleased you have a solution to something that's been bothering you. Restarting the shell is a usual requirement when changing a configuration file Apr 1, 2022 at 7:36
  • 1
    @ChrisDavies Thanks, I investigated further. The issue was only present in the login shell, because /bin/bash is too old and I was fooled by bash --version, because it is linked to /usr/local/bin/bash, a much newer bash that I installed via brew install bash in the past. The solution is to append /usr/local/bin/bash onto /etc/shells and then chsh -s /usr/local/bin/bash and now the feature is available in all shells, including the login shell. Jan 24 at 18:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .