RE: typeahead problem

["Andrej Borsenkow" <borsenkow.msk@sni.de>]

>
> No. For example, try this script:
>
>   for i in {1..}
>   do if read -q "REPLY?y/n: "
>      then print yes
>      else print no
>      fi
>      sleep 1
>   done
>
> After the first prompt, type aa quickly (or any other characters). On
> Linux and AIX, I get
>
>   y/n: a
>   no
>   ay/n: n
>   no
>   ay/n: n
>   no
>   ay/n: n
>   no
>   ay/n: n
>   no
>   $ a
>

On 3.1.5-patched I cannot reproduce it. It behaves exactly as I described.
It _smells_ like CLOBBERS_TYPEAHED though ...

> where $ stands for the shell prompt.
>
> I guess the problem is getzlequery() in Zle/zle_utils.c. The comment
> says: "If there are any characters in the buffer, this is taken as a
> negative response, and no characters are read."

No, what is called is getquery(); zlegetquery() is used only when you have
too long completion list.

 guess, this happens exactly because your system does _not_ clobbers
typeahed :)) getquery() can be told to purge input - but read -q does not do
it; it sees typeahed, takes it for "no", and then is called again - but
nothing was ever read from terminal, so it sees the same input again ...

As to why it is taken for "no" - imagine, you typed something _before_
read -q, and that was not completely consumed - you definitely does not want
some leftover "y" to remove your valuable files :) so it tries to play safe.

The only thing I don't understand, why it works on my system ...

This sounds like an
> exact description of what happens, and doesn't seem to make much sense.
> Why aren't the characters in the buffer read?? OTOH, there is no such
> bug on HP-UP, so I hesitate to hack the sources blindly...
>

there is not on my system as well ... but funnily enough, it probably means
a bug on my system :))  The ultimate place to correct it is bin_read(); call
getquery with last argument 1.

/andrej