4 ms·
This is properly viewed as a bug in bash (and most other shells). Shells can tell terminals to do "bracketed paste": the start and end of a pasted block is mark
by jimrandomh 11y ago
This is properly viewed as a bug in bash (and most other shells). Shells can tell terminals to do "bracketed paste": the start and end of a pasted block is marked with escape sequences. The correct behavior is to use bracketed paste, and to treat newlines inside pastes as multiline text input, not as a ready-to-execute signal.
Apparently that hasn't happened because of compatibility problems with broken terminals, plus perhaps a bit of work that no one's stepped up to do. If anyone wants to tackle this, the GNU readline library would be the place to do it.
- jwilk 11y agoBracketed paste can save you from accidental damage, but not from malicious pastes. As the fine article says, the end sequence can be inside the text you paste unless your terminal emulator filters out the bracketed paste characters (and last time I checked, at least urxvt didn't). Besides, teaching shell about bracketed paste could only help for pasting directly to shell; it won't help if you're pasting to vim (think of "^[:q!echo pwned^J") or cat (think of "^Decho pwned^J").
- jimrandomh 11y agoOk, sounds like it's two bugs - terminals definitely shouldn't pass through a bracketed paste end-marker, and probably shouldn't pass any control characters at all (ie, no esc or ^D). Passing special control characters through the clipboard is already unreliable, so I don't think this change would break anything legitimate.