[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-readline] Readline 6.2 regression vs. 6.1 on Mac OS X and perha
Re: [Bug-readline] Readline 6.2 regression vs. 6.1 on Mac OS X and perhaps elsewhere
Tue, 26 Jun 2012 09:51:37 +0200
Am 26.06.2012 um 03:36 schrieb Chet Ramey:
> On 6/24/12 6:08 PM, Max Horn wrote:
>> Dear GNU readline team,
>> I would like to report on an issue with readline 6.2 on Mac OS X 10.6.8
>> which does not occur with 6.1 and older. I also have reports for this on
>> 10.7 and also on older Mac OS X systems.
>> To reproduce the issue,
>> 1) compile the attached sample program (or any other program that sets
>> 2) run it inside Mac OS X' Terminal.app,
>> 3) paste some text, e.g. this line.
>> What happens is that you can see the text slowly appear, character by
>> character, like in a bad sci-fi flick. Pressing any key will cause the
>> remaining text to appear instantly.
>> I traced this back to the change in input.c, in rl_read_key(), from 6.1 to
>> 6.2. You see, on Mac OS X, if you paste a string, then all characters are
>> instantly visible as input to the program. So, if you paste 50 chars, you
>> will see 50 chars pending on stdin. Now when rl_event_hook is set, then
>> rl_gather_tyi() is used to read pending input. This function proceeds to
>> read all 50 pending characters at once. Previously, readline would then
>> proceed to feed this input to the program. Specifically, this is the old
> They key is that the hook needs to be run after the check for already-read-
> and-queued input, and it should only be run if rl_gather_tyi doesn't
> detect any input available. That was the issue with bash-4.1/readline-6.1:
> the input hook got run for every input character, whether anything was
> available or not, making it very hard to use it as something that got run
> after a specified timeout, for instance.
> Here's a patch against bash-4.2. Applying it to a standalone readline
> installation is left as an exercise for the reader. :-)
Thanks! Solved the exercise, too ;).
But I am puzzled a bit by this patch: First, this new code
! if (rl_get_char (&c) != 0)
is just a different way of saying
while (rl_event_hook && rl_get_char (&c) == 0)
which was part of the old code. Well, I guess it's a matter of taste whether to
use the first or the second. But note that this part of your patch alone
already fixes "my" issue.
What surprises me is the second change: You also added a "continue" in case
"rl_gather_tyi" did manage to read something. So this would reduce the number
of times the event hook is being called. So I assume this is meant to fix an
issue distinct from the one I reported, respectively to make the behavior of
this loop conform with the expected behavior you just described (only calling
the hook if a rl_gather_tyi completed with a *full* timeout, no data was read).
Thanks again & cheers,