From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27953 invoked by alias); 16 Nov 2017 00:52:47 -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: List-Unsubscribe: X-Seq: 42026 Received: (qmail 9141 invoked by uid 1010); 16 Nov 2017 00:52:46 -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(-1.9/5.0):. Processed in 1.935066 secs); 16 Nov 2017 00:52:46 -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=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: martijn@inlv.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Subject: Re: [PATCH] don't exit shell on [[ -o invalid@option ]] To: zsh-workers@zsh.org References: <0d6faa9a-fb69-8343-9630-a60d8f1bee0a@inlv.org> <171110143717.ZM16244@torch.brasslantern.com> <20171111124528.035a70ac@ntlworld.com> <38275e86-81c7-dbf8-544e-b0a399a4461d@inlv.org> <171111151905.ZM20139@torch.brasslantern.com> <20171112195657.74fb0b8a@ntlworld.com> <20171114122619.kqa4i2sth66mafrs@tarpaulin.shahaf.local2> <20171114235249.egcynklamldfcogv@tarpaulin.shahaf.local2> From: Martijn Dekker Message-ID: Date: Thu, 16 Nov 2017 02:52:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171114235249.egcynklamldfcogv@tarpaulin.shahaf.local2> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Op 15-11-17 om 01:52 schreef Daniel Shahaf: > Martijn Dekker wrote on Tue, Nov 14, 2017 at 15:22:35 +0200: >> Because >> (a) that's how all other [[ -o ... ]] implementations work, >> (b) that's what the current documentation in zshmisc.1 says that [[ -o >> ...] does, and >> (c) the canonical way to check if an option exists >> if (set +o someoption) 2>/dev/null; then ... >> works fine on all shells. >> >> Re (b), zshmisc.1 simply says that [[ -o ... ]] checks if the option is >> on. It says nothing about checking if the option exists, much less >> aborting the shell if it doesn't. > > (a) That's a fair point, but I'm not convinced it swings the balance. > (I agree that being compatible with bash/ksh is a plus.) I would note additionally that '[[' is a feature originally copied from ksh, so to me it does not seem like a good idea to differ from ksh behaviour without strong reasons. > (b) zshmisc.1 says "true if the named option var(option) is on". It > does not say that it's valid for var(option) not to be an option name at > all. Therefore, «[[ -o not_an_option ]]» is undefined behaviour; the > documentation does NOT promise that it would behave identically to [[ -o > an_unset_option ]]. In other words, the current behaviour is consistent > with the documentation. I don't follow that reasoning. By definition, a non-existent option cannot be on, so the condition "true if the named option var(option) is on" is always false for a non-existent option. Had it said "false if the named option var(option) is off", your point would have made sense to me. In either case, not documenting that the shell aborts on a non-existent option is definitely an omission. In fact that omission makes me wonder if that behaviour was intended in the first place. > (c) I don't follow your argument. Okay, so «(set +o option)» works, > what does that have to do with the behaviour of [[ -o not_an_option ]]? Nothing, except that there is already a well-known way of checking if an option exists, so it's not really necessary for [[ -o ... ]] to have that functionality, particularly if it comes at the expense of not being compatible with ksh and bash. >>> It's easy to imagine a situation in >>> which that'd be a bug: if INVALID_OPTION was added in zsh version N, is >>> set by default, and a plugin that was developed against version N is >>> installed by a user running version N-1. >> >> I don't see how that would introduce a bug. If a new option NEW_OPTION >> is introduced in zsh version N, default on, then [[ -o NEW_OPTION ]] can >> be used to run code dependent on that new option only if that new option >> is on. That code will then never be run on version N-1, which is what is >> expected. > > You're considering the "if" branch, I'm considering the "else" branch: > > if [[ -o NEW_OPTION ]]; then lorem; else ipsum; fi > > "lorem" will only run on zsh vN when the option is set, but "ipsum" will > run under vN with the option explicitly unset by the user AND under > vN-1. Since the option is on by default, vN-1 should take the "then" > branch. Fair point. However, zsh makes this easy to work around with its dynamic 'no-' prefix for all options. if [[ -o noNEW_OPTION ]]; then ipsum; else lorem; fi [...] > Okay, so how about if we demoted the fatal error to a warning? Like > this: > > % [[ -o not_an_option ]] || echo This gets run > zsh: [[: no such option: not_an_option > This gets run > % I think that would be fine, as well as returning status 2 along with it. I do think the warning (and the status 2) should be suppressed if POSIX_IDENTIFIERS or some other emulation-relevant shell option is active, so that 'emulate ksh' and 'emulate sh' reproduce ksh behaviour. Thanks, - Martijn