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 Message-ID: <56C10822.9010107@inlv.org> Date: Mon, 15 Feb 2016 00:05:06 +0100 From: Martijn Dekker User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: zsh-workers@zsh.org Subject: minor 'select' snag Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Seq: zsh-workers 37974 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. Thanks, - M. (Note of possible side interest: My experimental cross-platform shell library, "modernish" has a module providing its own 'select' implementation for POSIX shells. It mimics native implementations as closely as possible. On bash, *ksh and zsh, the module does nothing except a check for a particular shell bug. End result: all POSIX shells can use 'select'. There are just some minor differences to account for, including the above-mentioned one.)