From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12999 invoked from network); 8 Dec 1998 18:10:19 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 8 Dec 1998 18:10:19 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id NAA20591; Tue, 8 Dec 1998 13:08:42 -0500 (EST) Resent-Date: Tue, 8 Dec 1998 13:08:42 -0500 (EST) From: "Bart Schaefer" Message-Id: <981208100629.ZM6018@candle.brasslantern.com> Date: Tue, 8 Dec 1998 10:06:29 -0800 In-Reply-To: <366D1DC2.2A726728@rrz.uni-hamburg.de> Comments: In reply to Bernd Eggink "typeahead problem" (Dec 8, 1:38pm) References: <366D1DC2.2A726728@rrz.uni-hamburg.de> <000701be22aa$df12ab80$21c9ca95@mowp.siemens.ru> <366D32BB.79BDDC23@rrz.uni-hamburg.de> <000a01be22b7$512aedc0$21c9ca95@mowp.siemens.ru> <366D40E8.EAB05EE2@rrz.uni-hamburg.de> <001101be22c3$12fde9b0$21c9ca95@mowp.siemens.ru> In-Reply-To: <000701be22aa$df12ab80$21c9ca95@mowp.siemens.ru> Comments: In reply to "Andrej Borsenkow" "RE: typeahead problem" (Dec 8, 4:01pm) In-Reply-To: <366D32BB.79BDDC23@rrz.uni-hamburg.de> Comments: In reply to Bernd Eggink "Re: typeahead problem" (Dec 8, 3:07pm) In-Reply-To: <000a01be22b7$512aedc0$21c9ca95@mowp.siemens.ru> Comments: In reply to "Andrej Borsenkow" "RE: typeahead problem" (Dec 8, 5:30pm) In-Reply-To: <366D40E8.EAB05EE2@rrz.uni-hamburg.de> Comments: In reply to Bernd Eggink "Re: typeahead problem" (Dec 8, 4:08pm) In-Reply-To: <001101be22c3$12fde9b0$21c9ca95@mowp.siemens.ru> Comments: In reply to "Andrej Borsenkow" "RE: typeahead problem" (Dec 8, 6:54pm) X-Mailer: Z-Mail (4.0b.820 20aug96) To: Bernd Eggink , zsh Workers , "Andrej Borsenkow" Subject: Re: typeahead problem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"4O4xw1.0.g15.giMRs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4721 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Dec 8, 1:38pm, Bernd Eggink wrote: } Subject: typeahead problem } } read -q "REPLY?Yes or no: " && do_something } } Now if "do_something" takes some time and you type at least one } character in advance, 'read -q' behaves as if you are constantly typing } 'n', until you consume the pending character by a normal 'read'. In } other words, if you do NOT issue a normal read, EVERY following 'read } -q' will behave as if you had typed 'n', until the end of the script. } } Is there a rationale for this feature (which I still consider a bug, } because it makes 'read -q' nearly unusable, at least in scripts)? Andrej has been telling you mostly the right things ... On Dec 8, 6:54pm, Andrej Borsenkow wrote: } 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 getquery() function is called for the `rm *` check (the one DISabled by `setopt rmstarsilent`) and for spell checking (`setopt correct`) as well as for read -q. In those cases, typeahead is considered undesirable, and in the spell-check case zsh wants to leave it available in case the user intended it as input for the command. In the `rm *` case, on systems that support ioctl(FIONREAD), zsh consumes all the typeahead before it prints the query. On systems that don't support FIONREAD, zsh always consumes one character. The question is which of those two cases `read -q` should emulate. The decision made was to treat it like spell checking, leaving the typeahead alone when possible so that other commands may consume it. The way you get the "always consume one character" behavior is to use read -k1 "REPLY?Yes or no: " && do_something so having `read -q` available as an alternative that does NOT consume any characters is more flexible. The problem this leaves that there's no way to emulate "consume typeahead" from a script (because all other reads are blocking and wait for a newline). On Dec 8, 4:01pm, Andrej Borsenkow wrote: } Subject: RE: typeahead problem } } It is a "feature" of your particular OS. There is CLOBBERS_TYPEAHEAD define, } that tries to correct this. Unfortunately, CLOBBERS_TYPEAHEAD only applies when zle is setting up the terminal with zsetterm(), which doesn't happen during getquery(). On Dec 8, 5:30pm, Andrej Borsenkow wrote: } Subject: RE: typeahead problem } } I tried it here with 3.1.5 + patches. It looks, like ZSH takes the first } character on the line and ignores the rest. } } while read -q && sleep 10 } do } echo YES } done } y <- cursor immediately springs to the next line } yyyYES } ^^^ output by ZSH } <- note newline } YES } } Only first 'y' from 'yyy' is taken. Is it what you've seen? 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. On Dec 8, 6:54pm, Andrej Borsenkow wrote: } Subject: RE: typeahead problem } } The ultimate place to correct it is bin_read(); call } getquery with last argument 1. That would indeed change the behavior, but only when FIONREAD is supported. On Dec 8, 6:39pm, Bernd Eggink wrote: } Subject: Re: typeahead problem } } Hm, is there any reason to call getquery(x, 0) at all? I think the choice to pass purge==0 was partly to get consistent script behavior regardless of the availablilty of FIONREAD. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com