From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12055 invoked from network); 8 Dec 1998 15:57:40 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 8 Dec 1998 15:57:40 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id KAA16591; Tue, 8 Dec 1998 10:56:02 -0500 (EST) Resent-Date: Tue, 8 Dec 1998 10:56:02 -0500 (EST) From: "Andrej Borsenkow" To: "Bernd Eggink" , "zsh Workers" Subject: RE: typeahead problem Date: Tue, 8 Dec 1998 18:54:44 +0300 Message-ID: <001101be22c3$12fde9b0$21c9ca95@mowp.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <366D40E8.EAB05EE2@rrz.uni-hamburg.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Resent-Message-ID: <"H6-qj2.0.A34.ImKRs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4717 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > > 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