Ctrl-C ignored after pasting a long text in an X terminal emulator

[Vincent Lefevre]

The following issue is reproducible in several terminals, e.g. xterm
and GNOME Terminal, and several shells, e.g. bash and zsh.

1. From the shell in an X terminal emulator, run an X application
in foreground, e.g. emacs-gtk or xterm.

2. Paste a long text (e.g. the contents of /usr/share/doc/libc6/copyright
to choose an example every one has) in the terminal. Actually, only
the beginning of the text appears in the terminal.

3. Type Ctrl-C (one or several times) in the terminal.
But nothing happens.

4. Quit the X application that was started at step 1.

Result: many lines of the pasted text are executed by the shell!

This issue doesn't occur when the pasted text is short: the Ctrl-C
kills the X application via a SIGINT and nothing is executed.

You may wonder why one would paste a long text at step 2. In fact,
this happens by accident: I sometimes paste data in the terminal
instead of the application (typically Emacs). And this is really
annoying, in particular when lines contains the ">" character,
which has the effect to create files.

Is there any way to avoid this issue?

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[David Wright]

On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> The following issue is reproducible in several terminals, e.g. xterm
> and GNOME Terminal, and several shells, e.g. bash and zsh.
>
> 1. From the shell in an X terminal emulator, run an X application
> in foreground, e.g. emacs-gtk or xterm.
>
> 2. Paste a long text (e.g. the contents of /usr/share/doc/libc6/copyright
> to choose an example every one has) in the terminal. Actually, only
> the beginning of the text appears in the terminal.

Well, strictly, I see the end of the first portion of the pasted file.
The input buffer of xterm fills up, ironically at "Por" in one of the
lines containing "Portions Copyright … …". The beginning of the file
/usr/share/doc/libc6/copyright has scrolled off the top by then.

> 3. Type Ctrl-C (one or several times) in the terminal.
> But nothing happens.

I presume that's because the input buffer is already full, so
you'd need what I think they called an out-of-band signal,
like pressing Break used to do on an old teletype terminal.

> 4. Quit the X application that was started at step 1.
>
> Result: many lines of the pasted text are executed by the shell!
>
> This issue doesn't occur when the pasted text is short: the Ctrl-C
> kills the X application via a SIGINT and nothing is executed.

Yes, because in this case, ^C makes it into the input to xterm.

> You may wonder why one would paste a long text at step 2. In fact,
> this happens by accident: I sometimes paste data in the terminal
> instead of the application (typically Emacs). And this is really
> annoying, in particular when lines contains the ">" character,
> which has the effect to create files.
>
> Is there any way to avoid this issue?

Make sure that the application's data is saved, eg, ^X^S in emacs,
but don't exit the application, eg, ^X^C in emacs.

Then click on the X that closes the xterm window, which takes
down both xterm and the application with it. This is effectively
an out-of-band signal.

Finally, open another xterm with your WM's menu, to replace it.

Cheers,
David.

[Vincent Lefevre]

On 2023-01-21 21:19:06 -0600, David Wright wrote:
> On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> > 3. Type Ctrl-C (one or several times) in the terminal.
> > But nothing happens.
>
> I presume that's because the input buffer is already full, so
> you'd need what I think they called an out-of-band signal,
> like pressing Break used to do on an old teletype terminal.

Why doesn't the terminal have a function to flush and discard
the input buffer or have some reserved space for the intr and
quit characters? Or automatically increase the size of the
input buffer?

> > Is there any way to avoid this issue?
>
> Make sure that the application's data is saved, eg, ^X^S in emacs,
> but don't exit the application, eg, ^X^C in emacs.
>
> Then click on the X that closes the xterm window, which takes
> down both xterm and the application with it. This is effectively
> an out-of-band signal.

This is what I've sometimes done until now, but in general,
I don't want to lose the work I've done in the shell, such
as temporary variable settings or things related to the
background jobs.

[David Wright]

On Sun 22 Jan 2023 at 05:17:09 (+0100), Vincent Lefevre wrote:
> On 2023-01-21 21:19:06 -0600, David Wright wrote:
> > On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> > > 3. Type Ctrl-C (one or several times) in the terminal.
> > > But nothing happens.
> >
> > I presume that's because the input buffer is already full, so
> > you'd need what I think they called an out-of-band signal,
> > like pressing Break used to do on an old teletype terminal.
>
> Why doesn't the terminal have a function to flush and discard
> the input buffer or have some reserved space for the intr and
> quit characters? Or automatically increase the size of the
> input buffer?

IDK, I've never tried to write programs for the X system itself.

> > > Is there any way to avoid this issue?
> >
> > Make sure that the application's data is saved, eg, ^X^S in emacs,
> > but don't exit the application, eg, ^X^C in emacs.
> >
> > Then click on the X that closes the xterm window, which takes
> > down both xterm and the application with it. This is effectively
> > an out-of-band signal.
>
> This is what I've sometimes done until now, but in general,
> I don't want to lose the work I've done in the shell, such
> as temporary variable settings or things related to the
> background jobs.

The only suggestion I can give is that you start the applications
concerned with &, so that you get the xterm prompt back. 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.)

It's not a habit I use myself, because for some reason, I don't
happen to make that mistake. That might be because I put the cursor
very central in the emacs window when I paste large sections of text,
and that's because I have (setq mouse-yank-at-point t), which inserts
the text at point, not the cursor position.

Cheers,
David.

[Keith Bainbridge]

Sorry if this comes as a top post. I can't see the original text here


Isn't it shft-ctrl-c to copy from x-term?

[Sven Joachim]

On 2023-01-22 05:17 +0100, Vincent Lefevre wrote:

> On 2023-01-21 21:19:06 -0600, David Wright wrote:
>> On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
>> > 3. Type Ctrl-C (one or several times) in the terminal.
>> > But nothing happens.
>>
>> I presume that's because the input buffer is already full, so
>> you'd need what I think they called an out-of-band signal,
>> like pressing Break used to do on an old teletype terminal.
>
> Why doesn't the terminal have a function to flush and discard
> the input buffer or have some reserved space for the intr and
> quit characters? Or automatically increase the size of the
> input buffer?

This might be a limitation of Linux's pty(7) subsystem. The xterm
manpage mentions the following:

,----
| BUGS
| Large pastes do not work on some systems. This is not a bug in
| xterm; it is a bug in the pseudo terminal driver of those systems.
| Xterm feeds large pastes to the pty only as fast as the pty will
| accept data, but some pty drivers do not return enough information
| to know if the write has succeeded.
`----

See also https://bugs.debian.org/273194 in xterm. Disclaimer: I do not
have any expertise in that area.

Cheers,
Sven

[David Wright]

On Sun 22 Jan 2023 at 18:59:54 (+1100), Keith Bainbridge wrote:

> Isn't it shft-ctrl-c to copy from x-term?

Just to clarify: I didn't try to copy /from/ an xterm, I pasted
/into/ the xterm, "accidently" on purpose of course.

I used my normal MO to source the large paste, ie I typed ^A^C
in Firefox.

FWIW I don't see any effect from holding Shift while typing ^C
in xterm.

Cheers,
David.

[David Wright]

On Sat 21 Jan 2023 at 23:04:30 (-0600), David Wright wrote:
> On Sun 22 Jan 2023 at 05:17:09 (+0100), Vincent Lefevre wrote:
> > On 2023-01-21 21:19:06 -0600, David Wright wrote:
> > > On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
> > > > 3. Type Ctrl-C (one or several times) in the terminal.
> > > > But nothing happens.

> > > > Is there any way to avoid this issue?
> > >
> > > Make sure that the application's data is saved, eg, ^X^S in emacs,
> > > but don't exit the application, eg, ^X^C in emacs.
> > >
> > > Then click on the X that closes the xterm window, which takes
> > > down both xterm and the application with it. This is effectively
> > > an out-of-band signal.
> >
> > This is what I've sometimes done until now, but in general,
> > I don't want to lose the work I've done in the shell, such
> > as temporary variable settings or things related to the
> > background jobs.

I did try out sending various signals to the bash process.
Some, like HUP, close the xterm and its emacs child, but
there are signals, like ABRT, that close the xterm but
leave the child in the care of /sbin/init.

So, for example, you can still paste your large copy into
the (emacs) child and at least get that safely stored.

But I didn't find any signal that could regain control of
bash once you've given it indigestion, so the & idea is
still my only suggestion.

Cheers,
David.

[songbird]

Vincent Lefevre wrote:
...

> Is there any way to avoid this issue?

i'm not able to test either of these on your setup but
perhaps you can?

does it make any difference if you set the scrolling to
unlimited in your terminal profile? (i have this option
in my terminal).

also have you ever used xclip and would that make a
difference?

these are the only things i can think of.


songbird

[David Wright]

On Sun 22 Jan 2023 at 07:16:47 (-0500), songbird wrote:
> Vincent Lefevre wrote:
> ...
> > Is there any way to avoid this issue?
>
> i'm not able to test either of these on your setup but
> perhaps you can?
>
> does it make any difference if you set the scrolling to
> unlimited in your terminal profile? (i have this option
> in my terminal).

The amount visibly pasted into my xterm is exactly 4096 characters.
With the file in question, file:///usr/share/doc/libc6/copyright,
it's only 86 lines long:

$ wc /tmp/bit
86 606 4096 /tmp/bit
$

> also have you ever used xclip and would that make a
> difference?

I don't see what xclip buys you. If you have two windows open,
the xterm and the child application, and you click the middle
mouse button in the xterm by mistake instead of the child,
xclip will paste into the xterm in just the same way as the
OP described originally.

Were you to use xclip -o in some xterm to do the pasting,
instead of the mouse's middle button, how would you redirect
xclip's output to the open child process?

Cheers,
David.

[Richmond]

Vincent Lefevre wrote:
> The following issue is reproducible in several terminals, e.g. xterm
> and GNOME Terminal, and several shells, e.g. bash and zsh.
>
> 1. From the shell in an X terminal emulator, run an X application
> in foreground, e.g. emacs-gtk or xterm.
>
> 2. Paste a long text (e.g. the contents of /usr/share/doc/libc6/copyright
> to choose an example every one has) in the terminal. Actually, only
> the beginning of the text appears in the terminal.
>
> 3. Type Ctrl-C (one or several times) in the terminal.
> But nothing happens.

You could try pressing ctrl-z at this point to send the application into
background.

fg would bring it into foreground again.

I am not going to send that document into a terminal. It has asterisks
in it, what would happen if there were a line break and the next
characters were rm * ?

[Greg Wooledge]

On Sun, Jan 22, 2023 at 07:54:39PM +0000, Richmond wrote:
> > 3. Type Ctrl-C (one or several times) in the terminal.
> > But nothing happens.
> You could try pressing ctrl-z at this point to send the application into
> background.

It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
The xterm's pty's input buffer is full, and it simply ignores all keyboard
input from that point forward.

(Are people not actually *testing* these things before proposing them?)

[Vincent Lefevre]

On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> This might be a limitation of Linux's pty(7) subsystem. The xterm
> manpage mentions the following:
>
> ,----
> | BUGS
> | Large pastes do not work on some systems. This is not a bug in
> | xterm; it is a bug in the pseudo terminal driver of those systems.
> | Xterm feeds large pastes to the pty only as fast as the pty will
> | accept data, but some pty drivers do not return enough information
> | to know if the write has succeeded.
> `----
>
> See also https://bugs.debian.org/273194 in xterm. Disclaimer: I do not
> have any expertise in that area.

Thanks. Since several terminals are affected (I've tested xterm,
mlterm and GNOME Terminal), with exactly the same behavior, each
after 4095 characters, this is probably this bug.

[Vincent Lefevre]

On 2023-01-21 23:04:30 -0600, David Wright wrote:
> The only suggestion I can give is that you start the applications
> concerned with &, so that you get the xterm prompt back.

Perhaps. For Emacs, this is more complex because it can also
run in the terminal, and the ultimate solution could be to
write a shell function to run Emacs with "&" only when DISPLAY
is set and the -nw option is not used.

> 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.

I suppose that all the terminals do. And rxvt is even better:
it asks for confirmation when there is a control character,
such as a newline, in the data to be pasted. IMHO, it would
be a good idea if other terminals could have such a feature.
This would avoid my issue completely.

And concerning the shells, both bash and zsh do.

[David Wright]

Well /I/ certainly do. The only thing that surprises me is that in all
the years I've been pasting into an emacs window that's partly
overlaying its xterm parent, I've never accidentally pasted into
the xterm anything big enough to provoke this problem.

I tried pasting largeish text files (275KB) into both emacs
and xterm (the latter using cat >filename) and have had no
problems. I generated the copies in two ways, either ^A^C
in Firefox when displaying the original file, or with
xclip original-file, and pasted them with Sh-Insert.

All the pasted copies were identical with the original, so
I didn't hit bug #273194 mentioned by Sven.

Cheers,
David.

[David Wright]

On Mon 23 Jan 2023 at 03:17:43 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> > This might be a limitation of Linux's pty(7) subsystem. The xterm
> > manpage mentions the following:
> >
> > ,----
> > | BUGS
> > | Large pastes do not work on some systems. This is not a bug in
> > | xterm; it is a bug in the pseudo terminal driver of those systems.
> > | Xterm feeds large pastes to the pty only as fast as the pty will
> > | accept data, but some pty drivers do not return enough information
> > | to know if the write has succeeded.
> > `----
> >
> > See also https://bugs.debian.org/273194 in xterm. Disclaimer: I do not
> > have any expertise in that area.
>
> Thanks. Since several terminals are affected (I've tested xterm,
> mlterm and GNOME Terminal), with exactly the same behavior, each
> after 4095 characters, this is probably this bug.

I'm unconvinced. The bug was exhibited when the paste was into an
xterm running cat > /dev/null which should accept any amount of
input. I've catted 275KB to a real file, and got a perfect copy
every time.

In order to clarify what I see when I paste into the actual bash
prompt in an xterm, I edited the 275KB file to put all the text
on one line. When I pasted this version into the xterm, I see
the last section of the file, right up to the last character,
filling the window. As I have bracketed paste, all the text is
highlighted, and I can clear the input with ^U (because it's
bracketed), leaving a blank screen, or cancel it with ^C, which
leaves the detritus unhighlighted.

The 4KB limitation only kicks in when I paste into an xterm
while it is "otherwise engaged", ie it's running a windowed
application, and so the xterm is not accepting input in the
normal way, but presumably stuffing it into some sort of
4KB-sized buffer that bash acts upon only when the windowed
application quits.

The only post in bug #273194 that mentions this circumstance
is your own at message #40.

Cheers,
David.

[David Wright]

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.

Cheers,
David.

[Richmond]

Greg Wooledge <gr...@wooledge.org> writes:

> It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> The xterm's pty's input buffer is full, and it simply ignores all keyboard
> input from that point forward.
>
> (Are people not actually *testing* these things before proposing them?)

I didn't test it for the reason I stated. I think it would be better for
OP to test it as he won't do any more damage than he has already done.

I have come across occasions where ctrl-c doesn't work but ctrl-z does
however.

[to...@tuxteam.de]

On Mon, Jan 23, 2023 at 01:51:08PM +0000, Richmond wrote:
> Greg Wooledge <gr...@wooledge.org> writes:
>
> > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > The xterm's pty's input buffer is full, and it simply ignores all keyboard
> > input from that point forward.

[...]

> I have come across occasions where ctrl-c doesn't work but ctrl-z does
> however.

This is most probably for a totally different reason that the
one which seems at work here.

Cheers
--
t

[Greg Wooledge]

On Mon, Jan 23, 2023 at 01:51:08PM +0000, Richmond wrote:

> I didn't test it for the reason I stated. I think it would be better for
> OP to test it as he won't do any more damage than he has already done.

Here's how you can reproduce the problem without having to worry
about execution of the pasted text as commands:

1) Import some text into the paste buffer (xclip -i < somefile).
2) Open an xterm.
3) From the xterm, run "xeyes" or any other X client program, no ampersand.
4) Paste text into the xterm.
5) Try Ctrl keys. Observe that none of them work.
6) Close the xterm using the window manager controls.

> I have come across occasions where ctrl-c doesn't work but ctrl-z does
> however.

Sure, in a terminal that's in a normal state, that happens all the time,
if something is ignoring SIGINT. The entire point of this thread is
that when the input buffer of the pty behind the xterm fills up, none
of the signals that are generated by keyboard input in a terminal work
any longer. The only resort is to close the xterm.

[Richmond]

No that wasn't the entire point of the thread. The OP didn't know the
cause, it was presumed by David Wright that it was caused by the buffer
filling up. But it could have been caused by some spurious character in
the file, e.g. ctrl-s.

[Vincent Lefevre]

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.

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.

[Vincent Lefevre]

On 2023-01-22 23:27:27 -0600, David Wright wrote:
> On Mon 23 Jan 2023 at 03:17:43 (+0100), Vincent Lefevre wrote:
> > On 2023-01-22 11:33:57 +0100, Sven Joachim wrote:
> > > This might be a limitation of Linux's pty(7) subsystem. The xterm
> > > manpage mentions the following:
> > >
> > > ,----
> > > | BUGS
> > > | Large pastes do not work on some systems. This is not a bug in
> > > | xterm; it is a bug in the pseudo terminal driver of those systems.
> > > | Xterm feeds large pastes to the pty only as fast as the pty will
> > > | accept data, but some pty drivers do not return enough information
> > > | to know if the write has succeeded.
> > > `----
> > >
> > > See also https://bugs.debian.org/273194 in xterm. Disclaimer: I do not
> > > have any expertise in that area.
> >
> > Thanks. Since several terminals are affected (I've tested xterm,
> > mlterm and GNOME Terminal), with exactly the same behavior, each
> > after 4095 characters, this is probably this bug.
>
> I'm unconvinced. The bug was exhibited when the paste was into an
> xterm running cat > /dev/null which should accept any amount of
> input. I've catted 275KB to a real file, and got a perfect copy
> every time.

Indeed, this works fine with xterm and GNOME Terminal, even with
"xterm; cat > foo" and the paste done before quitting the xterm
(or whatever command that will not terminate immediately). But
mlterm has some problems with that.

I suppose that the terminal can detect when the pty will no longer
accept additional characters. And the paste resumes as soon as
input is read by "cat".

With xterm, if I do the large paste with middle-click and type
abc<Ctrl-C>def, then the end of the paste is missing, probably
because the Ctrl-C occurred during the last write to the pty.

[Vincent Lefevre]

On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> The xterm's pty's input buffer is full, and it simply ignores all keyboard
> input from that point forward.

They are actually not ignored, but delayed by the terminal emulator.
This is an issue because Ctrl-C (the intr character) is normally
taken into account immediately (with a SIGINT generation), even if
earlier characters have not been read yet by the command.

And this is apparently the same for the other special characters
as defined by stty.

[Vincent Lefevre]

On 2023-01-24 10:03:31 +0000, Richmond wrote:
> No that wasn't the entire point of the thread. The OP didn't know the
> cause, it was presumed by David Wright that it was caused by the buffer
> filling up. But it could have been caused by some spurious character in
> the file, e.g. ctrl-s.

I know that in general, the file does not contain special characters
for the terminal. BTW, Ctrl-S does not prevent Ctrl-C from working:

cventin% sleep 999
abc^Sde^C
cventin%

[David Wright]

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.

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.

[David Wright]

On Tue 24 Jan 2023 at 17:18:17 (+0100), Vincent Lefevre wrote:
> On 2023-01-22 15:35:08 -0500, Greg Wooledge wrote:
> > It doesn't work, presumably for the same reason that Ctrl-C doesn't work.
> > The xterm's pty's input buffer is full, and it simply ignores all keyboard
> > input from that point forward.
>
> They are actually not ignored, but delayed by the terminal emulator.
> This is an issue because Ctrl-C (the intr character) is normally
> taken into account immediately (with a SIGINT generation), even if
> earlier characters have not been read yet by the command.
>
> And this is apparently the same for the other special characters
> as defined by stty.

How did you determine that they're actually received by the terminal
emulator after the buffer is full? IOW where are they being stored?

Cheers,
David.

[David Wright]

In that case, AFAICT, ^C still works, as the buffer's not full
(assuming it occurs early enough in the input), but it can kill
the foreground application too. ^Q also performs its normal function,
but that just reverts to the undesirable outcome of filling up
the buffer. And, of course, you've expanded the original problem
to one of pasting binary data.

Cheers,
David.

[David Wright]

AFAIK whenever you interrupt a process with ^C, you're going to
have a problem with knowing exactly how much of the processing was
completed, and what sort of "tidying up/throwing away" was done.

The OP talked about posting "a long text". If you relax this to
include binary data, it wouldn't surprise me if surprises occur.

Cheers,
David.

[Vincent Lefevre]

I don't know where they are stored (this is probably part of the
terminal code), but

1. Create file1 with
printf "%d\n" `seq 9999` > file1
2. Select the contents of file1.
3. In a terminal (xterm in my case), type "some_app ; cat > file2",
where some_app is an X application or "sleep 10", for instance.
4. Paste with the middle button in the terminal.
5. Type Ctrl-C in the terminal.
6. Quit some_app (or let it end, e.g. in case of sleep).

I get something like:

[...]
9982
9983
9984
9985
9986
9987
99^C

in the terminal, and file2 ends with "9987" due to the Ctrl-C.

Another try:

[...]
9979
9980
9981
9982
9983
9984
99^C

and this time, the file ends with "9912". This is not surprising
as the characters probably appear in the terminal before they are
processed by "cat". Since the writes to the pty by xterm and the
process by "cat" are concurrent, one doesn't exactly obtain the
same result at each test. But in every case, the Ctrl-C is taken
into account only near the end.

And a test with GNOME Terminal:

[...]
9996
9997
9998
9999
^C

and the file ends with "9181".

[to...@tuxteam.de]

Actually, AFAIK, its not the terminal emulator, but the PTY which does
that translation. So your argument would be valid if there's something
/before/ the PTY doing the buffering.

Cheers
--
t

[Vincent Lefevre]

On 2023-01-24 10:36:05 -0600, David Wright wrote:
> On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:

[...]

> > 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.

With bracketed paste, the lines remains in the command line at the
prompt until the user has typed the [Enter] key to run them. So the
user can also type Ctrl-C to prevent any execution (or he can edit
the command).

For instance, in zsh:

cventin:~> foo1
foo2
foo3

If I type [Enter], I get:

zsh: command not found: foo1
zsh: command not found: foo2
zsh: command not found: foo3
cventin:~[127]>

But instead of [Enter], if I type Ctrl-C, I just get:

cventin:~[1!]>

Nothing has been executed. (The exit code 1 is strange and may be
caused by a bug in some hook. This occurs only if I do a Ctrl-C
directly after a paste, otherwise I get 130 as expected.)

> In terms of accidents, you've just driven a car at a brick wall,
> and it runs into it, as expected.

No, with modern shells, bracketed paste is precisely there to avoid
such kind of issues.

[David Wright]

On Tue 24 Jan 2023 at 18:29:38 (+0100), Vincent Lefevre wrote:
> On 2023-01-24 10:36:05 -0600, David Wright wrote:
> > On Tue 24 Jan 2023 at 15:34:49 (+0100), Vincent Lefevre wrote:
> [...]
> > > 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.
>
> With bracketed paste, the lines remains in the command line at the
> prompt until the user has typed the [Enter] key to run them. So the
> user can also type Ctrl-C to prevent any execution (or he can edit
> the command).

You're preaching to the converted; see
https://lists.debian.org/debian-user/2023/01/msg00562.html
two posts back.

My comment was with respect to your point 2, which was about
non-bracketed paste, and which was snipped off the top of your post.

BTW are you implying that dash does bracketed paste? I didn't know that.

> For instance, in zsh:
>
> cventin:~> foo1
> foo2
> foo3
>
> If I type [Enter], I get:
>
> zsh: command not found: foo1
> zsh: command not found: foo2
> zsh: command not found: foo3
> cventin:~[127]>
>
> But instead of [Enter], if I type Ctrl-C, I just get:
>
> cventin:~[1!]>
>
> Nothing has been executed. (The exit code 1 is strange and may be
> caused by a bug in some hook. This occurs only if I do a Ctrl-C
> directly after a paste, otherwise I get 130 as expected.)
>
> > In terms of accidents, you've just driven a car at a brick wall,
> > and it runs into it, as expected.
>
> No, with modern shells, bracketed paste is precisely there to avoid
> such kind of issues.

Quite clever, that. You quote my comment after some anecdote of yours
that gives it the opposite context, so you can then disgree with it.

BTW I don't know anything about nooks and zsh. As I said at the end
of my previous post, I'm not really interested in

> > testing the gamut of releases, terminals and shells.

But if you are, then it might be worth your posting a summary of your
findings in the form of a table that others could understand, rather
than in a back and forth of over-snipped posts.

Cheers,
David.

[Curt]

On 2023-01-24, Vincent Lefevre <vin...@vinc17.net> wrote:
>
>> In terms of accidents, you've just driven a car at a brick wall,
>> and it runs into it, as expected.
>
> No, with modern shells, bracketed paste is precisely there to avoid
> such kind of issues.
>

I thought it was designed to avoid formatting problems when pasting code
into a text editor.

[Vincent Lefevre]

About this, Ctrl-U is just a shell feature. Contrary to bash, it is
not really usable in zsh to erase long pastes (unless one changes
the default bindings). But Ctrl-C is fine in zsh.

> My comment was with respect to your point 2, which was about
> non-bracketed paste, and which was snipped off the top of your post.
>
> BTW are you implying that dash does bracketed paste? I didn't know that.

No, the opposite: I'm showing above that dash does not support
bracketed paste. This means that running an X application in
background with "&" would not solve the problem with dash, and this
would actually be worse with short pastes (which are cancellable
with Ctrl-C or Ctrl-Z when an application is running in foreground).
I normally don't run X application from dash (which I use mainly for
testing shell behavior), but this doesn't mean that this will never
occur.

[Greg Wooledge]

On Thu, Jan 26, 2023 at 06:34:24PM +0100, Vincent Lefevre wrote:
> About this, Ctrl-U is just a shell feature. Contrary to bash, it is
> not really usable in zsh to erase long pastes (unless one changes
> the default bindings). But Ctrl-C is fine in zsh.

Ctrl-U is bound to "kill" at the terminal level (e.g. stty(1)). It's
more than just a shell feature. You can use it in any setting where
a terminal is in "canonical mode", e.g. "cat" with no arguments reading
from a terminal, or a terminal's login prompt.

I don't know a lot about zsh, but I ran it, typed some letters, and
pressed Ctrl-U, and they were all erased as expected.

One difference that I did notice in zsh is that its handling of Ctrl-U
after a bracketed paste is different from bash's. I used "seq 3 | xclip -i"
to load three harmless lines into the paste selection, and then pasted
it into zsh, and into bash, and pressed Ctrl-U in each of them. In the
zsh case, only the third line was erased, and the first 2 were still
there, and were executed when I pressed Enter. In bash, all 3 lines
were erased, and Enter didn't execute any of them.

Whether that's a bug in zsh, I can't say.

[David Wright]

So it's just a case of choosing the appropriate workaround for
your release/terminal/shell. (I suppose I should add: in whatever
combination.) Will wayland matter? :)

> > My comment was with respect to your point 2, which was about
> > non-bracketed paste, and which was snipped off the top of your post.
> >
> > BTW are you implying that dash does bracketed paste? I didn't know that.
>
> No, the opposite: I'm showing above that dash does not support
> bracketed paste. This means that running an X application in
> background with "&" would not solve the problem with dash, and this
> would actually be worse with short pastes (which are cancellable
> with Ctrl-C or Ctrl-Z when an application is running in foreground).
> I normally don't run X application from dash (which I use mainly for
> testing shell behavior), but this doesn't mean that this will never
> occur.

Ditto as above. Sorry & doesn't work for you. I guess there's
a point at which you run out of options for the computer to
"automatically" work around the effects of your actions, and you
just have to put up with negative consequences of your mistakes.

Cheers,
David.

[Vincent Lefevre]

On 2023-01-26 13:09:31 -0500, Greg Wooledge wrote:
> On Thu, Jan 26, 2023 at 06:34:24PM +0100, Vincent Lefevre wrote:
> > About this, Ctrl-U is just a shell feature. Contrary to bash, it is
> > not really usable in zsh to erase long pastes (unless one changes
> > the default bindings). But Ctrl-C is fine in zsh.
>
> Ctrl-U is bound to "kill" at the terminal level (e.g. stty(1)). It's
> more than just a shell feature. You can use it in any setting where
> a terminal is in "canonical mode", e.g. "cat" with no arguments reading
> from a terminal, or a terminal's login prompt.

Shells do not use "canonical mode". In zsh, Ctrl-U is handled by zle,
bash uses readline, AFAIK, so that it depends on the Ctrl-U binding.
See examples in the readline(3readline) man page.

> I don't know a lot about zsh, but I ran it, typed some letters, and
> pressed Ctrl-U, and they were all erased as expected.

But the point is multiline, as you did then:

> One difference that I did notice in zsh is that its handling of Ctrl-U
> after a bracketed paste is different from bash's. I used "seq 3 | xclip -i"
> to load three harmless lines into the paste selection, and then pasted
> it into zsh, and into bash, and pressed Ctrl-U in each of them. In the
> zsh case, only the third line was erased, and the first 2 were still
> there, and were executed when I pressed Enter. In bash, all 3 lines
> were erased, and Enter didn't execute any of them.
>
> Whether that's a bug in zsh, I can't say.

I would say that's expected and this is actually a bug in bash:
"kill-whole-line" means to kill the line, not the whole text.

[David Wright]

On Fri 03 Feb 2023 at 23:59:38 (+0100), Vincent Lefevre wrote:
> On 2023-01-26 13:09:31 -0500, Greg Wooledge wrote:
> > I don't know a lot about zsh, but I ran it, typed some letters, and
> > pressed Ctrl-U, and they were all erased as expected.
>
> But the point is multiline, as you did then:
>
> > One difference that I did notice in zsh is that its handling of Ctrl-U
> > after a bracketed paste is different from bash's. I used "seq 3 | xclip -i"
> > to load three harmless lines into the paste selection, and then pasted
> > it into zsh, and into bash, and pressed Ctrl-U in each of them. In the
> > zsh case, only the third line was erased, and the first 2 were still
> > there, and were executed when I pressed Enter. In bash, all 3 lines
> > were erased, and Enter didn't execute any of them.
> >
> > Whether that's a bug in zsh, I can't say.
>
> I would say that's expected and this is actually a bug in bash:
> "kill-whole-line" means to kill the line, not the whole text.

But the whole text /behaves/ as one line containing embedded newlines,
which you will quickly realise if you ever try to edit it before
pressing Enter. If you want to edit something that's apparently
"three lines up", you can't press ↑ to move up three lines:
you have to hold down the ← key and wait until it reaches said
position. And you can add and remove the embedded newlines at will.

When you press Enter, a "transformation" takes place, and the paste
is interpreted in the context in which it finds itself, which can
lead to surprises.

Cheers,
David.