6k buffer bug in shells

[Sten Westerback]

Hi

After trying to figure out what causes a weird bug, which i can see with 
lots of shells and connection types (local terminal on linux, ssh + 
numerous shells on AIX and putty (linux & windows)+numerous shells on AIX) 
i though i would ask makers of my favorite shell.

The problem is that when i paste in longer texts instead of just typing 
the result isn't as expected. It seems that after a certain amount of 
characters the shell drops a few characters but then continues. The number 
of characters dropped depends on the line with (with 50 it's 4, with 64 it 
was 12 etc). And with slightly larger amounts of text there is also a 
pause before it continues while one would expect the flow to be continous 
with a simple task like this,

Here is a simple file which when copied to clipboard and then pasted into 
a shell should produce the obvious text in /tmp/chartestRESULT.txt... but 
it just doesn't always.


Here a result file sample with error shown at row starting with  3JJJ and 
5WWW ::



I have tried workarounds such as:
- breaking into 6 k blocks to append to file
- replacing  cat >> file ..  << homedoc    with   echo " ... \n ... \n ... 
\n" >> file
- term=dumb    which i first thought fixed it.. but later problem 
appeared. I didn't yet test to change terminal on all ssh levels.

It seems that the shell or something involved, such as clipboard 
functionality or ssh protocol, doesn't like to be flooded by a couple of 
MB of text.
Hope you can point me towards a fix or work-around.

What i'm actually attempting is pasting in of Base64 encoded data, broken 
into 64 byte rows, as a simple way to transfer small binary files from a 
workstation to a host that is behind a longer chain of ssh sessions. This 
works perfectly for smaller files but then i noticed this problem. Here 
example of failing rows from row 140 forward:
Input
MUEOSDFqQMHIwCY9GQwKx2iiFQ/CFQb7d/pH0IWmdqs9PEHr4ZNPBnt4x9AzWl0ijz9nPlG7d1hd2MFZ
/fpgXXdTXS8/D4yxCq0++IvzZJEdPKHjm4zaOdGY8fimhUbMngxadrEfp8rsQmP51/AFgujz8GdCu4DZ
Rk60GmzrIBuZ8OODeOY2z+jZE01xEj5hYvl0FE0m8HLlKS2I5Ju9xWbWdCf0qXw9blL5XGb2/XvavTWT
HRIJdtsKFK5jMUaTfDMPJidvp2Di6omIJc3Q8V/bisv9Juj3jAKBDZR+oc2SR6+C+MTqyzfMpWvTNp9P

Result:
MUEOSDFqQMHIwCY9GQwKx2iiFQ/CFQb7d/pH0IWmdqs9PEHr4ZNPBnt4x9AzWl0ijz9nPlG7d1hd2MFZ
/fpgXXdTXS8/D4yxCq0++IvzZJEdPKHjm4zaOdGY8fimhUbMngxadrEfp8rsQmP51/AFgujz8GdCu4DZ
Rk60GmzrIBuZ8OOD
HRIJdtsKFK5jMUaTfDMPJidvp2Di6omIJc3Q8V/bisv9Juj3jAKBDZR+oc2SR6+C+MTqyzfMpWvTNp9P

So something dropped the 
eOY2z+jZE01xEj5hYvl0FE0m8HLlKS2I5Ju9xWbWdCf0qXw9blL5XGb2/XvavTWT 
In this case after 141*81 + 64 = 11485 characters  on 142nd row.

Environment: 1:
Redhat linux 2.6.32-696.6.3.el6.x86_64 #1 SMP Fri Jun 30 13:24:18 EDT 2017 
x86_64 x86_64 x86_64 GNU/Linux
GNU Bash-4.1
GNOME Terminal 2.31.3 

Environment 2:
AIX 7.1.5.0 TL05
Putty Development snapshot 2017-06-21.d618974  (Windows 64 bit)

- Sten

Ellei edellä ole toisin mainittu: / Unless stated otherwise above:
Oy IBM Finland Ab
PL 265, 00101 Helsinki, Finland
Business ID, Y-tunnus: 0195876-3 
Registered in Finland

chartest.txt
Description: Text document

chartestRESULT.txt
Description: Text document