From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14501 invoked from network); 8 Dec 1998 21:25:15 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 8 Dec 1998 21:25:15 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id QAA27778; Tue, 8 Dec 1998 16:24:16 -0500 (EST) Resent-Date: Tue, 8 Dec 1998 16:24:16 -0500 (EST) From: "Bart Schaefer" Message-Id: <981208132228.ZM6695@candle.brasslantern.com> Date: Tue, 8 Dec 1998 13:22:28 -0800 In-Reply-To: <001a01be22d9$e99fbc80$21c9ca95@mowp.siemens.ru> Comments: In reply to "Andrej Borsenkow" "RE: typeahead problem" (Dec 8, 9:38pm) References: <001a01be22d9$e99fbc80$21c9ca95@mowp.siemens.ru> <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> <981208100629.ZM6018@candle.brasslantern.com> <366D723D.A710FD4E@uni-hamburg.de> In-Reply-To: <366D723D.A710FD4E@uni-hamburg.de> Comments: In reply to Bernd Eggink "Re: typeahead problem" (Dec 8, 7:38pm) X-Mailer: Z-Mail Lite (5.0.0 30July97) To: "Andrej Borsenkow" , "zsh Workers" , Bernd Eggink Subject: Re: typeahead problem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"-mnRt.0.zn6.0aPRs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4725 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Dec 8, 9:38pm, Andrej Borsenkow wrote: > Subject: RE: typeahead problem > > > 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. Your machine executes "sleep 10" so quickly that you can't type before it finishes? > In other words, if system does have FIONREAD but clobbers typeahead, zsh > always reads the first character and forgets the rest. That shouldn't be how it works. If the system clobbers typeahead in the way described in Src/Zle/zle_main.c, then the typeahead should get lost before getquery() has a chance to read even the first character. However, it is the case that zsetterm() and getquery() are inconsistent about their use of FIONREAD. zsetterm() calls ioctl(FIONREAD) _before_ attaching to the TTY, whereas getquery() attaches first and then calls ioctl(). If the zsetterm() code doesn't cause a problem with spurious SIGTTIN and SIGTTOU signals, it should be safe to move the FIONREAD code in getquery() to above the attachtty() and setcbreak(). > CLOBBER_TYPEAHED is used in zsetterm() but not in getquery() ... Yes, but that doesn't make any difference [except for the inconsistency I just noted], because getquery() already performs an equivalent test on the value obtained from ioctl(FIONREAD). > ... Well, do we need to change modes (setcbreak()) _before_ doing read? Yes, but apparently not before doing ioctl(FIONREAD). On Dec 8, 7:38pm, Bernd Eggink wrote: > Subject: Re: typeahead problem > Bart Schaefer wrote: > > > 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. > > IMHO this decision was wrong, but it's probabely too late now. Actually, I don't get the impression that `read -q` is all that widely used, and as it's already inconsistent depending on FIONREAD, this might be a reasonable change. We should probably float it on zsh-users first, though. > > get the "always consume one character" behavior is to use > > > > read -k1 "REPLY?Yes or no: " && do_something > > Hm, no. You have to write something like > > typeset -u REPLY > read -k1 "REPLY?Yes or no: " > [[ $REPLY == Y ]] && do_something Well, yes, but you should still test for success of read. I assumed you were already testing $REPLY inside "do_something" ... if you don't need the answer captured in $REPLY, you can just do read -q "?Yes or no: " && ...