From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9933 invoked by alias); 26 Sep 2016 18:23:37 -0000 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-Seq: 39448 Received: (qmail 22296 invoked from network); 26 Sep 2016 18:23:37 -0000 X-Qmail-Scanner-Diagnostics: from kahlil.inlv.org by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(37.59.109.123):SA:0(-3.0/5.0):. Processed in 0.496552 secs); 26 Sep 2016 18:23:37 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: martijn@inlv.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at inlv.org does not designate permitted sender hosts) Subject: Re: minor 'select' snag To: Zsh hackers list References: <56C10822.9010107@inlv.org> <20160215124803.6d07e989@pwslap01u.europe.root.pri> From: Martijn Dekker Message-ID: <453f6dc7-692f-845f-1314-1352724d07c3@inlv.org> Date: Mon, 26 Sep 2016 17:59:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160215124803.6d07e989@pwslap01u.europe.root.pri> Content-Type: multipart/mixed; boundary="------------4E0A2A832E72891F9D27257B" --------------4E0A2A832E72891F9D27257B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Op 15-02-16 om 12:48 schreef Peter Stephenson: > 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. This is from February and no action seems to have been taken since. I spent some time looking into it now. Please consider the simple patch attached. It makes zsh 'select' act exactly like bash and *ksh: if user presses Ctrl-D (EOF), the REPLY variable is cleared, but if there is an interrupt or error (e.g. Ctrl+C) the REPLY variable remains unaffected. To reiterate, this makes it possible to check for EOF by checking the emptiness of REPLY without having to manually initialise REPLY first, like on bash, ksh93 and mksh. Thanks, - Martijn --------------4E0A2A832E72891F9D27257B Content-Type: text/x-patch; name="select.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="select.patch" diff --git a/Src/loop.c b/Src/loop.c index fa7602e..3b9d021 100644 --- a/Src/loop.c +++ b/Src/loop.c @@ -289,6 +289,8 @@ execselect(Estate state, UNUSED(int do_exec)) } } else str = (char *)getlinknode(bufstack); + if (!str && !errflag) + setsparam("REPLY", ztrdup("")); /* EOF (user pressed Ctrl+D) */ if (!str || errflag) { if (breaks) breaks--; --------------4E0A2A832E72891F9D27257B--