Re: bracketed-paste-mode should default to "off"

[Karl O. Pinc]

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 <kop@karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein