Re: Writing to bash's tty too fast: workarounds?
George Nachman gnach...@gmail.com writes: In the case of bash + readline, would it be feasible to avoid readline changing the terminal settings while reading a here document? From the view of readline there is no difference between reading a line inside or outside of a here-document. Both should allow full access to the editing capabilities of readline. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Writing to bash's tty too fast: workarounds?
Thanks for getting back to me, Chet. The theory about the kernel's handling of a full input queue seems likely. In the case of bash + readline, would it be feasible to avoid readline changing the terminal settings while reading a here document? Seems like the only remedy if the kernel is misbehaving in this case. On Tue, Apr 10, 2012 at 9:20 AM, Chet Ramey chet.ra...@case.edu wrote: 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 ... EOF 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 termios(4)). 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. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Writing to bash's tty too fast: workarounds?
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 ... EOF 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. Is this a known issue? I can reproduce it on Linux as well, but it's much less severe. The test case can be found here: http://pastebin.com/as3KjEcq To build on Mac, compile with gcc bug.c -o bug -DMACOS To build on Linux: gcc bug.c /usr/lib/libutil.a -o bug It should produce a file in your home directory called mytestfile.txt that looks like this: ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXY ZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWX YZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVW etc. On Linux, you get the occasional short line. On Mac OS, you get only a few lines and they're very long. I can reproduce this on Mac OS with the latest bash source build with default settings. Thanks for your help, George
