On 2023-01-23 03:11:59 +0100, Vincent Lefevre wrote: > On 2006-10-14 15:56:10 -0400, Thomas Dickey wrote: > > On Sat, Oct 14, 2006 at 08:20:14PM +0200, Andrew Moise wrote: > > > I still see this misbehavior with xterm 210-3.1 and > > > linux-image-2.6.17-2-686 2.6.17-9. > > > > I can see it (now) with a 2.6.15 kernel (814 lines copied). > > I also note that Branden got no followup from the kernel people. > > This also occurs with > > Linux zira 6.1.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18) > x86_64 GNU/Linux > > and xterm, mlterm and GNOME Terminal at least. This would confirm > a kernel pty bug (unless this is a documented pty limitation, in > which case the applications would have to take it into account... > but they could try to implement a workaround in any case). > > For me, with the above kernel, the limit is 4095 bytes. > > An annoying consequence is that Ctrl-C no longer works, which can > yield buggy commands executed by the shell after an accidental > paste while a foreground X command is running (presumably because > bracketed paste is not in effect, so that each newline character > validates each line as a command). See > https://lists.debian.org/debian-user/2023/01/msg00520.html
Actually, in my case (where I do a large paste after starting a command that doesn't consume input, typically an X command), this is a different, but related issue. The characters are not really lost, but delayed. Still, the behavior is incorrect: the characters, including Ctrl-C, are kept in some xterm buffer, so that the Ctrl-C doesn't have an immediate effect: it takes effect only near the end of the paste (after the command has ended), and this is too late. -- Vincent Lefèvre <vinc...@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)