Re: Ctrl-C ignored after pasting a long text in an X terminal emulator
On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 23:27:11 -0600, David Wright wrote:
> > On Mon 23 Jan 2023 at 04:15:38 (+0100), Vincent Lefevre wrote:
> > > On 2023-01-21 23:04:30 -0600, David Wright wrote:
> > >
> > > > In this case, if I paste the large file, I do see almost the start
> > > > of the file (I seem to lose just the first line, which rolls off the
> > > > top), and ^C still works, returning to the prompt with return code
> > > > 130.
> > > >
> > > > (I don't know whether all terminals behave like this: I just use
> > > > xterm myself.)
> > >
> > > This should work if the terminal and the shell both support
> > > bracketed paste.
> >
> > Bracketed paste allows me to erase all the input with ^U.
> > But I didn't think you needed bracketed paste for ^C to work.
>
> This is not what I meant. The context was the following one:
>
> | The only suggestion I can give is that you start the applications
> | concerned with &, so that you get the xterm prompt back.
>
> So, if there is a prompt, the shell will get the large paste
> (possibly with some loss of data due to the pty bug), and there
> will be no issues with Ctrl-C itself because the shell will have
> read all the input data.
As I say, I haven't observed bug #273194 myself, while doing my
best to provoke it.
> However, before the user can type Ctrl-C, the shell will interpret
> the characters from the large paste immediately. There are 2 cases:
>
> 1. If bracketed paste is supported, then all the characters will just
> be interpreted as quoted characters, like if Ctrl-V were typed before
> each character. In particular, a newline character will not validate
> the command, but will be inserted in the command itself (where it can
> appear either as a line break if the shell supports multiline editing,
> or as ^J).
>
> 2. If bracketed paste is not supported, then a newline character will
> validate the command (except if it happens to be in quoted text). So
> one will get lots of buggy commands run by the shell, which is the
> same issue as the ignored Ctrl-C without the prompt.
>
> For instance, if I paste the following 3 lines
>
> foo1
> foo2
> foo3
>
> in dash, I get:
>
> $ foo1
> foo2
> foo3
> sh: 1: foo1: not found
> $ sh: 2: foo2: not found
> $ sh: 3: foo3: not found
> $
>
> Then I can type Ctrl-C, but it occurs at a prompt with no input yet,
> and the 3 commands have already been executed.
Well, sure, you've pasted lines into a shell, and they get executed.
I don't think you want to prevent that.
In terms of accidents, you've just driven a car at a brick wall,
and it runs into it, as expected.
But my context for using & was bullseye, xterm and bash, not
testing the gamut of releases, terminals and shells.
AIUI bracketed paste is now the default since bullseye, and
if you turn it off, you have to carry the risks: accidental
pasting is one of the most obvious.
Cheers,
David.
Reply to: