Per Bothner wrote: >> On 1/31/22 20:47, Karl O. Pinc wrote: >> My argument is that Unix should come with the training >> wheels off, by default. > > That's not an argument, it's a preference.
True. A design preference. The argument is that this has been the design preference for Unix since day 1. A counter argument is that there've been "newbie friendly" distros turning the knobs and adding guard rails for a long time now. I'd argue that the "core" should continue to follow the original design principals and default to a uniform design. The design choices can then be tweaked in whatever direction system integrators think benefit the user's they serve. That also is a preference; but I recognize that things do change. And that there's little point in arguing about what's "real Unix". I will happily accept whatever the maintainers choose in the end. >> "Simple" and "obvious" seems more useful than "safe". > > Not in the world we're living in, full of malware and phishing attacks. > > The experts can turn off safety, if they wish. For beginner, the default > should be "safe". For the beginner, the default should be usable. (More below.) > I also think bracketed-paste-mode=on is just plain more useful. Agreed. There is additional utility. Although I only see the more advanced user utilizing the utility. (More below.) >> It took a couple of months of being annoyed at my pastes not "working" > > In what sense? The main point of bracketed paste mode, as explained to me in the few communications I've had about it, is to allow editing of pasted text before acceptance. With bracketed paste on, when pasting anything containing a newline, it is as if there's a "Press enter to continue" invisible dialog that pops up. There is no way to tell that your terminal is waiting for you to do something. Typing "sleep 10\n" and pasting "sleep 10\n" look exactly the same but behave completely differently. The former sleeps 10 seconds. The latter sleeps forever, or at least until a newline is actually typed. IMO this would be completely confusing to a beginner. How are they supposed to know that performing a paste operation requires multiple steps before the computer will accept their paste? It is simple and obvious when a newline always causes a command to execute. It is complicated and confusing when a newline causes differing behaviors depending on how it got there. Especially when there's no visual indication of the difference between one sort of newline and another. When first encountering this phenomenon I let the terminal sit for half an hour doing nothing before I realized that it was indeed doing nothing. (Having pasted a command that I did not expect to complete instantly.) I'm still nervous about entering the "extra newline" needed to make the pasted commands execute. Although I've not yet hit a case where an accidental extra press of the enter key at the wrong time might break things, even having to think about it is one more distraction. I agree it would be nice to make things safer by default but I don't really see that happening here. I'd like to see such a substantive change justified. What is the threat model? Maybe I've not got the proper perspective because I think about/use the features of readline primarily at the terminal prompt. Is a beginner, who's the target of malware or phishing, really going to edit something they've pasted after pasting it before execution? Is the extra step really going to allow to removal of the malice? I don't see such a user, who's already decided to cut-and-paste from some email (or more typically, some random website), pausing after pasting and then deciding to research and correct whatever flaw in the pasted text the attacker has placed there. In my experience beginners don't even know they can edit the command line. Yes, the more sophisticated user could find it convenient to use the terminal, instead of a scratch file, to review and correct. (Especially things like those nasty Unicode mdash-s when websites mung up arguments.) But to justify what I see as a substantive and un-intuitive change to the default user interface I'd like to see an explanation of what threats this change is going to mitigate and how it's going to do so. At least if the change is going to be justified on the basis of improving security. On re-reading the readline man page I see that the declared point of bracketed paste mode is to "prevent pasted characters from being interpreted as editing commands". That seems a worthy goal, and not invasive. But the actual implementation has altered newline behavior, which I see as a big change that makes the system significantly more complicated. (I did spend a half hour+ figuring out why I can't "just cut and paste". And I wouldn't want to have to be the person explaining this feature to a beginner if I was providing them with instructions involving the command line. That puts this change in the "significant" category for me. And I see only very advanced users being able to figure out what settings need to be adjusted to turn bracketed paste mode on or off.) Perhaps there's a way to enable this by default but not have newlines affected? On, "On-but-for-newline", and Off, defaulting to "On-but-for-newline"? Or maybe the newline-related behavior is its own setting and defaults to off. The newline related behavior, to my ignorant eye, has nothing to do with preventing inadvertent "editing" of the command/input buffer that alters in a malicious way the apparent pasted commands. And the ability to edit pasted text before acceptance has nothing to do with malicious alteration of pasted commands via embedded editing strings. Separating the treatment of newlines and the opportunity to edit pasted text from the treatment of editing commands embedded in pasted text, seems to me, could be the best of all worlds. Until then I argue for defaulting bracketed paste mode to "off". Regards, Karl <[email protected]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
