bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] Pasting large amounts of text into readline-enabled p


From: Chet Ramey
Subject: Re: [Bug-readline] Pasting large amounts of text into readline-enabled programs truncates parts of the lines of the text being pasted
Date: Thu, 12 Jul 2012 22:53:35 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

On 7/12/12 9:57 PM, Edmar Wiggers wrote:

>> I cannot reproduce it on Mac OS X pasting into Mac OS X Terminal.  I can
>> reproduce it using xterm (so far only a remote xterm running on a REHL6
>> system, but I've just started looking).  It looks like a file around 6.6K
>> (250 lines of what you sent, decoded) is enough to reproduce it.  The
>> weird thing is that when you run this using strace, the characters that
>> are missing in the output are not shown as being made available to read(2).
>> read never reads them.
>>
>> As I said, I've just started to look again, so I will keep on.
> 
> Thanks a lot for looking into it Chet! Max Horn was also unable to
> reproduce the bug on Mac OS X, but he did reproduce it in gnome
> ( http://lists.gnu.org/archive/html/bug-readline/2012-06/msg00006.html ).
> 
> Just for information: When I was first googling about this I found...
> https://groups.google.com/forum/#!msg/linux.kernel/PYgS2MyNQfw/8S-eCFcFg9sJ
> ..., but it seems they've been unable to find a kernel regression on it.

More strange stuff: on xterm on Mac OS X, there are repeated characters
and segments of text in the garbled output (e.g., CONFIG_CGR-CONFIG_CGR-
CONFIG_CGR-CONFIG_CGR...) and read() sees and reads all of them.  It's not
something that readline is doing with a buffer internally.  That plus what
I noticed before seems to fit with the google groups linux kernel message
thread you referenced, but it's not Linux-specific.

Clearly it looks like it's something that readline is doing, or the
interaction between readline and the terminal, because turning off line
editing results in good output.  It's just not clear what it is.  It
might be that readline just isn't keeping up with all of the single-
character reads it's doing, but as the kernel discussion notes, the
kernel should stop shoving input when its internal buffer fills up.

My guess at this point is not a Linux kernel bug -- I can reproduce it
on Mac OS X, but that's where readline sees extra input instead of
dropping some -- but some interaction between xterm and a program that
switches the terminal between raw and cooked modes.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]