If I type 'seq -w 0 999' in one xterm, and cut-and-paste the output into another xterm which is running 'cat > /dev/null', I see only the numbers 0 through 818. Cut-and-pasting 500 lines of 7 characters each, or 250 lines of 15 characters each, gives me similar results. Oddly enough, 1000 lines of 7 characters each seem to cut-and-paste properly. This may well be yet another example of my recent streak of reporting non-xterm bugs to the xterm package; it happens in aterm and rxvt as well, for example. It happens with both bash and zsh, and with X-Win32 as well as Debian's X server. emacs and abiword both accept 1000 lines of 3 characters each properly. Presumably, then, it's a library bug, but I'm not sure how to go about tracking down which library is responsible. Sorry. Filing it against xterm seems better than keeping it to myself :-).
that's odd. My first inclination regarding a limit on cut/paste is the (system-dependent) caveat at the end of the xterm manpage: 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 suc- ceeded. But what "large" is depends on the system. Perhaps the limit is only 4kb and someone's made fixes to the pty support to splice together 4kb chunks. If the splicing isn't working properly, there could be some loss near the multiples of 4kb.
Hm, that sounds plausible (it would also explain #184176, which has been slightly annoying me for years). I never knew ptys were a best-effort transport :-). If that's true, then it sounds like this is a kernel bug, right? I tried briefly to come up with a clean reproduction case, but ptys don't play well enough with cat/echo/etc for me to do it right now.
hmm - officially the kernal has no bugs. In practice, its behavior alters from one snapshot to the next. But #243314 is perhaps related to this. Mostly I've been using the 2.4.18, etc. (I did some testing for a 2.6.4 kernel but didn't see the problem as reported, but it's on my list until I have a large enough time slot to finish rewriting a chunk of xterm to better handle bursts of output).
retitle 273194 xterm: characters from paste buffer lost at roughly 4kB intervals [kernel pty bug?] thanks [I am not subscribed to -kernel; please CC the bug on replies.] Kernel guys, do you want to take this one off my hands?
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.
This bug has been present since at least the 5.14 kernel. It's profoundly annoying and shouldn't have been allowed to slip into production release. Maybe someone could fix the problem this year? It's really pathetic when things that worked perfectly 20 years ago are broken because of shoddy code changes made since.
In reviewing this bug, it appears that the 4k limit (in 2004) is not an issue any more. I was able to copy/paste 100k without dropping characters. ymmv :-)
The more recent comments on this issue are actually unrelated. If a paste is large enough to fill the shell's line-buffer, then that will "delay" a ^C. I've seen a few comments about that, and it's not due to xterm. xterm isn't going to detect ^C in the input and magically honor that in some undocumented out-of-band signalling mechanism. The reported issue did not depend on that, so unless someone can provide detailed instructions on how to bump into a 4000-character limit on current systems, this can be closed.
The more recent comments on this issue are actually unrelated. If a paste is large enough to fill the shell's line-buffer, then that will "delay" a ^C. I've seen a few comments about that, and it's not due to xterm. xterm isn't going to detect ^C in the input and magically honor that in some undocumented out-of-band signalling mechanism. The reported issue did not depend on that, so unless someone can provide detailed instructions on how to bump into a 4000-character limit on current systems, this can be closed.