> That was not my concern - if a program acts poorly, we should report bugs
> against that program. But of course, it would be nice, if the underlying web
> of bash + Konsole could handle such cases gracefully - e.g. by discarding the
> rest of the half-eaten input. You'd not go to a restaurant and eat what the
> other guests left on their plates :D

OK. I didn't address this case again because I thought we had
already resolved it.

This is a non-starter from a shell perspective: there is no way
to distinguish such input from typeahead the user intended to
direct to bash. I'm not interested in adding an option to flush
input when calling readline; I don't think that's productive.

Any option to flush unconsumed input from the pty when a
foreground process exits would have to come from the terminal
emulator side, and it's very difficult to do there, since the
terminal emulator process is not the parent of the foreground
process in question and would not be notified of its
termination.

> My idea is to transition into a better world, where bracketed paste would be
> the only way of pasting.

I'm simply not interested in this. It would not be useful, and would be extremely user-hostile. I can't see cat, or sed, or
awk being changed to understand the bracketed-paste escape
sequences or to read input a character at a time. I can't imagine
a bigger insult to users than to tell them that suddenly they
can't continue to use the workflow they're used to because the
programs in it don't understand the new-style pasting, and there
is no other option.

> The protocol of bracketed paste and the evolution of it happens in the
> interface between Konsole and bash. Neither of you can change it onesided.

Surely you don't think Konsole is the only terminal emulator that
implements bracketed-paste mode. I don't even use Konsole.

> Yes, it removes the ambiguity of "pasting vs. typing" into bash directly by
> introducing a fresh inconsistency of treating pasted text differently, whether
> or not it is inserted before the current command exits.

This doesn't make sense, or it's phrased poorly. The trouble
scenario you're using, as I understand it, is a program that enables bracketed-paste mode but doesn't read all of its input
before exiting. That is indeed a problem, because there might
not be a program that understands bracketed paste available to
read that input, but it's a problem that a terminal emulator
will have to solve, and there's no solution that will be right
all the time.

The `issue' of whether or not text is pasted and not read before
a foreground command exits is not new.

If you're arguing against the entire concept of bracketed paste,
since that's what `introduces a fresh inconsistency', I'm not
interested in having that discussion.

> Then why not make an effort, to extend this protection to text pasted while
> another program is executing?

The current state of the art requires every program to be
modified.

> Just a little though experiment - would it be possible, to get a terminal in
> "strict" mode, that only accepts bracketed pastes? Programs, that don't
> implement the protocol will never see any input. And the paste will either be
> rejected (e.g. with a beep) or be delayed until some program offers, to accept
> pasted text in bracketed mode. They do register in a way, so that Konsole
> knows, to wrap the Escape sequences or not, right?

You'd have to ask the folks who implement terminal emulators, or
who maintain libraries used by terminal emulators. I don't really
pay attention to that.

If you want terminals to reject pastes to programs that don't
enabled bracketed paste mode, that seems like a pretty user-
hostile change, even if you make it a non-default option a user
has to enable.

> Question is, if this would gather enough momentum, to get programmers in
> rewriting their programs/commands to accept bracketed paste - or if such a
> feature would be disabled by default and never used again?

My guess is that programs that read their input character by
character and expect to read from a terminal might change, and
programs that simply read standard input will never change (and
should not).

> For the whole bracketed paste feature, I only learned about it, because it was
> "forced" on me be some default switch. Yes, I got confused by it at first and
> I would have loved, to get some information dialog and choice upfront, instead
> of just dumping it on me.

This sounds like something you should take up with your vendor.

> OK, I see, we shall not discard what someone typed while e.g.
> sleep 5 is executing - that's a valid point.

That's a user expectation. (And the expectation of someone who
types ahead while executing any program -- like glxgears --
that doesn't enable bracketed paste mode.)

> Only now I am confused, what was the purpose of inventing the
> "bracketed paste protocol"? Is it just meant to be a "best-
> effort-don't-shoot-your-foot" or is there some real security 
> consideration behind it?

Bracketed-paste mode was invented to remove ambiguity: to signal
that text is explicitly the result of a paste and not the result
of typed input. Programs generally react to that as readline does,
by disabling any special meaning attached to the characters.

So yes, there is a security consideration there: how can we
paste something and ensure that pasting it will have no side
effects?

But you're correct: programs have to explicitly enable it or
be prepared to understand the bracketed-paste prefix and suffix,
or both.

> So the ambiguity is here:
> a) run input accepting program -> text paste is expected to
> complete immediately

Not necessarily. Programs read as much input as they need to do
their work. POSIX explicitly specifies that the shell, for
example, only reads as much input as it needs to parse a complete
command, leaving other data on standard input for a program it
invokes.

However, if a program enables bracketed-paste mode, it should
read all of the text between the bracketed paste prefix and
suffix, to avoid confusing other programs with the escape
sequences.

And usually, it works as you expect: programs read and process
their input until they get an EOF.

> b) run non-input-program -> pasted text shall be retained, so
> it can be treated as if pasted directly into bash WITHOUT
> automatic execution, prompting for another press of Enter. The
> pasted text becomes indistinguishable from any other keyboard-
> input.

No. This is true of bracketed paste mode (and there are people
who have complained about that), but in general a newline that
appears in the input buffer is treated as a newline and has
whatever context-dependent meaning a newline has. That means if
the pasted text contains a newline, bash will read a newline and
execute the command it's reading (the most common case).

> How I understand it, Konsole as the GUI needs to finish the
> paste as it happens, and is forced to decide on a paste method
> (bracketed or not) BEFORE the program exits. There might even
> come a second paste after this - so waiting is not an option.

Konsole needs to decide, preferably via a user setting, how the
pasted text appears to the process on the other side of the pty.
If the user (or program, like bash), has enabled bracketed paste
mode, Konsole has to send the bracketed paste prefix, the text
to be pasted, and the bracketed paste suffix into the pty input
queue. If there's no bracketed paste mode in effect, it just
stuffs the text to be pasted into the queue.

Konsole doesn't know whether a program that is reading from the
other side of the pty exits -- that program is not a child of
Konsole, and, unless the program that exits is the shell, which
is, it won't know. If the shell exits, Konsole will be notified,
and can react appropriately by destroying the window, in which
case none of this matters.

So Konsole's primary responsibility here is to make the pasted text appear on the slave side of the pty's input queue.

> The critical moment is, when bash returns to power and has a
> look at what is waiting in the buffer, potentially pasted or
> typed. How hard would it be, to again put this in a linebuffer
> and ask the user to confirm again by pressing Enter or further > editing the line, as if he did not paste a line-break / press
> Enter before the blocking fg-program exited?

That would defeat user expectations. Users who do not use
bracketed paste mode expect newlines in pasted text to be treated
as newlines. Some intentionally disable bracketed paste mode
because it doesn't do this. Bash doesn't need to be second-
guessing the user like that: if you aren't using bracketed paste
mode and you don't want text you paste to be immediately accepted
and potentially executed, don't put a trailing newline in it.

> In my opinion, this would streamline the experience of pasting
> with an additional Enter (irrespective of program running or
> not) - but at the same time force an additional Enter when
> typing commands while a program is running.

It would do exactly the opposite. It would insert an extra step
that would make a process that has worked one way for a long time
more cumbersome.

> Also I marvel, if
> someone is relying on the current behavior e.g. by sending fake
> key-events asynchronously not waiting for the individual
> commands to finish. But then, shouldn't they just submit their
> input as a script file?

This happens more often than you think. To the user, they are not
`fake' key events: they are real keys that they pressed, and they
expect those key presses to be honored. And since this is
primarily an issue with interactive shells, retroactively making
something a script is not an attractive option.

So you're saying that there is input on the master side of the pty that bash reads when the child process exits? This is an indeterminate situation.

Flushing the input buffer defeats all typeahead. How is bash supposed to know whether the input it reads is intended or `left over' from a terminated child process? For instance, it's easy to type input while, say, `sleep 5' is running, and bash reads and executes the input when sleep exits. This is common and expected.

If someone wants this flush to happen, there should be a way to configure the terminal emulator to flush the input on the pty when a child process exits, but it should not be the default setting.