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