Chet Ramey wrote:
There have been several interesting discussions on this topic, most centered on Linux: https://groups.google.com/d/msg/linux.kernel/PYgS2MyNQfw/orRVLXtinOwJ http://lists.gnu.org/archive/html/bug-readline/2012-07/msg00004.html http://lists.gnu.org/archive/html/bug-bash/2012-04/msg00065.html http://lists.gnu.org/archive/html/bug-readline/2013-07/msg00013.html
---- Seems most of those were 5-6 years ago. Might explain why I can't reproduce it, though I'm pasting into a remote TTY window in each case. (one SecureCRT, other xterm) -- w/about 290899 chars pasted. Only case I've seen of pasted chars being eaten is if the source code was indented with TAB... then various autocomplete prompts swallow chars randomly based on number of matching autocomplete entries.
including the following comment: "So, after quite a lot of extra hours spent on this, we were able to track MOST of the breakage to this commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f23eb2b2b28547fc70df82dd5049eb39bec5ba12" Margarita Manterola and Maximiliano Curia did most of the work; here is the final summary of their findings (the subsequent thread is interesting as well): https://lkml.org/lkml/2013/7/25/205 The question is how to deal with large amounts of data in a situation where the tty modes keep getting changed after each newline, while preserving acceptable behavior for the usual case of cooked mode. Chet