Bob Proulx writes: > halfdog wrote: > > I tried to figure out, which of the three involved components > > might be at fault. The component stack is: > > > > * terminal > > * local shell > > * ssh > > * remote shell > > Note that the recent bash 5.1rc1 is testing with bracketed-paste-mode > enabled by default for the first time. If you have upgraded recently > then that is the most likely change which has triggered this new > behavior. (It's the new reverse video paste and region which cause > problems for me.) > > You might try putting > > set enable-bracketed-paste off > > into your libreadline configuration ~/.inputrc file to see if that > changes what happens for you. That would isolate the change to bash > 5.1rc1 enabling this mode by default in that test release. Sorry, this one got lost somehow... I tested it, the inputrc change exacltly reverts Bash behavior to the one before the update. Due to the SSH client being able to delete arbitrary files on the local machine, forwarding arbitrary ports, which might also be possibly to trigger when accidentially copy&pasting malicious content containing (hidden) SSH "~C" commands (only the timing of the input seems relevant, not tested how far that can be influenced when e.g. copying from a browser window - at least a standard terminal to terminal copy&paste is not sufficient), while not having investigated that I think i will stick to the "cat > /dev/null" solution to temporarily disable bracketed copy&paste (and therefore enable SSH command copying) just when I really want to copy and paste SSH "~C" command(s) from a cheat sheet. hd _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev