Re: 6k buffer bug in shells

[L A Walsh]

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