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.
