RE: typeahead problem

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

> -----Original Message-----
> From: Bart Schaefer [mailto:schaefer@brasslantern.com]
>
>
> I see the following in a patched 3.0.5 and in both patched and unpatched
> 3.1.5:
>
> zagzig% while read -q && sleep 5
> while> do echo YES; done
> y				<-- newline echoed immediately
> yyyYES				<-- I typed yyy, YES echoed
> after 5 sec.
> n				<-- echoed immediately after YES
> zagzig% yyy			<-- typeahead now appears at the prompt
>
> } Well, manual says "read -q reads only one character" so it is really
> } confusing. Currently it "reads the line and takes the first character".
> } Who's wrong - binary or manual?
>
> On my system, at least, zsh does not consume the line, only the first y
> of the four that I typed.  That agrees with the manual, except that the
> manual doesn't discuss the typeahead behavior.
>

I know now, what happens here. See later

> I think the choice to pass purge==0 was partly to get consistent script
> behavior regardless of the availablilty of FIONREAD.
>

Unfortunately, it's not consistent. Consistent would be to read the first
character of typeahead.

About why it works and does not work.

getquery() changes tty modes, and on some systems that flushes unread input
("clobber typeahead") Looks, like my system is so fast, that even if I type
several characters, the first one is read by _first_ read -q, then the
second is read by the _second_ read -q and the others are simply lost.

In other words, if system does have FIONREAD but clobbers typeahead, zsh
always reads the first character and forgets the rest. CLOBBER_TYPEAHED is
used in zsetterm() but not in getquery() ... I think it is quite possible
... Well, do we need to change modes (setcbreak()) _before_ doing read? that
is, if FIONREAD is defined we check and either output NL
and return or read up typeahead and go on. the same, if we read the first
character of typeahead instead of assuming "no".

/andrej