[Top][All Lists]

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

Re: Writing to bash's tty too fast: workarounds?

From: Chet Ramey
Subject: Re: Writing to bash's tty too fast: workarounds?
Date: Tue, 10 Apr 2012 12:20:22 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 6/13/11 1:45 AM, George wrote:
> I'm the maintainer of a terminal emulator on Mac OS and a user
> reported that if he pastes a large string of the form:
> cat << EOF > whatever.txt
> blah blah blah
> blah blah blah
> ... etc for 100k ...
> That the output is badly mangled. I can reproduce this consistently
> with a smallish test program. Having traced into readline, the culprit
> seems to be that readline fiddles with the terminal between lines of
> input (I'm pretty sure the things done in set_tty_settings() are
> responsible, but I haven't proved it yet). This seems to cause it to
> drop some or all of the input that's in the input buffer.

Since readline is intended to read a single line of input at a time, it's
natural that it modifies the terminal settings before it reads any data
and after it's read a complete line.  The code is careful to use flags to
tcsetattr(3) that force the system to wait until all output has drained
and does not throw away input characters.

I suspect that the cause is the kernel's behavior when the input queue
is full.  Readline doesn't use IXON/IXOFF, so there won't be any
stopping when the queue is full (see the description of IXOFF in

If you want to paste large amounts of data, you're not interested in any
input line editing, so it makes sense to turn off editing as a workaround
(set +o emacs +o vi) before running the command using the here document.

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