Re: Bracketed paste causes readline() to return multiple lines

[Chet Ramey]

On 1/2/24 7:21 PM, Martin Buck wrote:
> On Tue, Jan 02, 2024 at 04:43:40PM -0500, Chet Ramey wrote:
> > I see how this can be confusing. The whole idea behind bracketed paste is
> > that everything in the pasted text is inserted into the readline line,
> > without any of the characters causing execution of any readline function
> > that might be bound to them. Think of it as if you had executed the
> > readline `quoted-insert' command before every character in the pasted text.
>
> Thanks for your quick explanation! May I suggest a big fat warning in the
> docs next to the "single line, no newline" description of readline(), making
> library users more aware of the fact that they can't rely on always getting
> just a single line?

Readline has always been able to return lines with embedded newlines.

> > It's always been possible to do this, even before bracketed paste, by using
> > quoted-insert.
>
> Sure, but before bracketed-paste-defaults-to-on you had to try really hard
> to make an appplication that expects a single line to misbehave whereas now
> you can trigger this easily and involuntarily with each paste operation. And
> to the average user, it's probably not obvious at all what's going on and
> how to avoid it.

That's on the application, isn't it? If I can trick an application into
misbehaving just because I quote a newline, I'd report that as a bug.

> > Bracketed paste is all or nothing: either it's on and everything that
> > gets pasted is inserted into the line buffer, or it's off and every pasted
> > character is treated as if it had been typed at the keyboard and causes
> > execution of any readline function bound to it.
>
> I thought the main idea behind bracketed paste is the possibility to review
> what you're pasting before it takes effect as Karl described in the other
> email in this thread.

That's one reason, yes, but not the primary one. From the earliest days of
bracketed paste support (2014), one of the reasons for doing it was the
increased security afforded by not auto-executing the contents of a paste.
It's a greater benefit, though, based on the number of questions and
reports I got before implementing it, to be able to stop the questions like
"where did the tabs go in the text I pasted into the shell?" or "why can't
I paste this character into the shell?" since the pasted characters will
never invoke an editing command or corrupt the terminal/line buffer.

The other issue is that it was always possible for a user to prevent
execution of pasted input:

https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00234.html

but there was no way to prevent pasted characters from invoking editing
functions without turning off line editing. Bracketed paste addresses all
of these in addition to being considerably more efficient.

> I can see use in having this on by default, but I'm
> not so sure about the "don't execute bound functions" part of it.

Do you think that pasting a set of characters including, say, tabs should
preserve all the characters in the paste? Or should you drop some of them
or have them affect the insert position? (I hate to pick on tabs, but that
was the most common report.)


> So for the time being, I'll probably teach calc
> https://github.com/lcn2/calc/ (that's the application where a user noticed
> that multi-line-paste no longer works as expected) to handle multi-line
> return values from readline() properly to make it indepedent of however
> bracketed paste might behave in the future.

I think this would improve its robustness.

> BTW, thanks a lot for maintaining readline and bash! I wrote an article
> about the new features in bash 2.0 for the German Linux Magazin in 1997 and
> it's cool to see that it's still maintained by the same hard-working hands
> :-)

Thanks for your kind words.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/