Daniel Colascione wrote: > Well, I don't know whether Chet left the feature enabled by > default. I hope he did, though, since preventing execution of pasted > commands is one of the feature's key benefits. In bash, you should > be able to execute a pasted command sequence by typing RET after the > paste, but a paste by itself should never begin execution.
I use paste into the shell with an embedded newline in order to immediately execute a command *a lot*. If that were removed I would be very unhappy. However I read from Chet's replies that this is not the case. So I am not worried. Just voicing a counter opinion that this shouldn't be removed. If you want it then you should enable it. This is like many other options available in the shell. They are optional. > For better or worse, people copy and paste commands from websites > all the time. Even if a bit of shell looks innocuous, a malicious > bit of JavaScript could change the pasted text at the last second > without the user being aware of the switch. Then the browser shouldn't copy it. The place to fix the problem is in the browser. A problem with a browser should not break cutting and pasting in general. > (Tynt uses this technique to slightly less malicious ends.) If > pasting in a terminal immediately begins execution, there's no > opportunity to review pasted code. With bracketed paste support, the > shell requires additional user interaction after a paste to begin > execution, making this attack much less effective. I am very happy this is a feature you like. However I would hate that feature. It should definitely not default to on or it will make people like me very unhappy. Bob
