Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-AuditID: cbfec7f5-f79b16d000005389-e2-56c1c9063d6d Date: Mon, 15 Feb 2016 12:48:03 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: minor 'select' snag Message-id: <20160215124803.6d07e989@pwslap01u.europe.root.pri> In-reply-to: <56C10822.9010107@inlv.org> References: <56C10822.9010107@inlv.org> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsVy+t/xa7psJw+GGVzYJ2JxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4Mp4/3cNY8EyoYsL1f2wNjK/5uhg5OSQETCTWTDvAAmGLSVy4 t56ti5GLQ0hgKaPE8qZ7UM4MJomlcxtZIJxzjBJzFrxhhXDOMkpseHWBvYuRg4NFQFWi73EV yCg2AUOJqZtmM4LYIgLiEmfXngdbISygIHH303Z2EJtXwF7i3aLHrCA2p4CGxJpV+8DqhQTU Jc6c/wwW5xfQl7j69xMTxHn2EjOvnGGE6BWU+DH5HthMZgEtic3bmlghbHmJzWveMsPMuXF3 N/sERuFZSFpmIWmZhaRlASPzKkbR1NLkguKk9FwjveLE3OLSvHS95PzcTYyQcP66g3HpMatD jAIcjEo8vBFnDoQJsSaWFVfmHmKU4GBWEuF1PHwwTIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv zF3vQ4QE0hNLUrNTUwtSi2CyTBycUg2MkTUsATP7fAS8mc+tV8uY87/uulW+l3L02cUfrP7f ffZtUu/qcudXhyXtPeI/x9/smR+n/dyTze+0yhOLusm/Zcuz/gXcKQ41KOG621lnl/yWxTrU c3n3tItPd+/87fz77V+pwNlTFkU5Fd5qSzqpWjQhpr9Zz9o4hfGKyrPrZmwHi10UP3crsRRn JBpqMRcVJwIAtrlu+mMCAAA= X-Seq: zsh-workers 37982 On Mon, 15 Feb 2016 00:05:06 +0100 Martijn Dekker wrote: > I'm analysing the behaviour of 'select' in various shells and found a a > way in which it's different in zsh from bash, ksh93 and {pd,m}ksh. > > If a user presses Ctrl-D (EOF) within a 'select' loop, the REPLY > variable is left unchanged on zsh. On the other shells with 'select', it > is cleared, which is the same behaviour as 'read' (including 'read' on > zsh) and seems more logical. This makes it possible to decide whether to > continue after the loop by testing for the emptiness of $REPLY without > having to initialise it before entering the loop. It would be nice if > this worked the same way on zsh. This looks easy. I don't think there's any existing moral right to expect REPLY to be unaffected in such circumstances. diff --git a/Doc/Zsh/grammar.yo b/Doc/Zsh/grammar.yo index 2a76964..7488829 100644 --- a/Doc/Zsh/grammar.yo +++ b/Doc/Zsh/grammar.yo @@ -279,8 +279,10 @@ is set to the var(word) corresponding to this number. If this line is empty, the selection list is printed again. Otherwise, the value of the parameter var(name) is set to null. The contents of the line read from standard input is saved -in the parameter tt(REPLY). var(list) is executed -for each selection until a break or end-of-file is encountered. +in the parameter tt(REPLY); this is set to the empty string if no +input was done for the benefit of code following the tt(select). +var(list) is executed for each selection until a break or end-of-file is +encountered. ) cindex(subshell) item(tt(LPAR()) var(list) tt(RPAR()))( diff --git a/Src/loop.c b/Src/loop.c index 19d7f73..dd4b282 100644 --- a/Src/loop.c +++ b/Src/loop.c @@ -224,6 +224,7 @@ execselect(Estate state, UNUSED(int do_exec)) size_t more; LinkList args; int old_simple_pline = simple_pline; + int reply_set = 0; /* See comments in execwhile() */ simple_pline = 1; @@ -303,6 +304,7 @@ execselect(Estate state, UNUSED(int do_exec)) more = selectlist(args, more); } setsparam("REPLY", ztrdup(str)); + reply_set = 1; i = atoi(str); if (!i) str = ""; @@ -327,6 +329,8 @@ execselect(Estate state, UNUSED(int do_exec)) break; } done: + if (!reply_set) + setsparam("REPLY", ztrdup("")); cmdpop(); popheap(); fclose(inp);