From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17232 invoked by alias); 14 Nov 2017 12:34:20 -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: 42021 Received: (qmail 15076 invoked by uid 1010); 14 Nov 2017 12:34:20 -0000 X-Qmail-Scanner-Diagnostics: from out4-smtp.messagingengine.com 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(66.111.4.28):SA:0(-1.9/5.0):. Processed in 10.476706 secs); 14 Nov 2017 12:34:20 -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,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=3rd7k9/raf/dl4SNGeF1e1iwr4qxf F77a8ztQ0GbrW0=; b=wjO5jVKRLgPsrpzeCPxqOkvgU8zhIcltBuYSDFZXp2dmD dTkEbKny7GiHokK+GC0ulq7hSBDD9gcbchRkqsExcNxSkkjRJJqmIXmOI05E6wRg WN88t/mUF61hiq4FoY5LgarE6KuqpGjjnd0WkjuSDzgUZReFoyxQp/B2xNZIt4u1 WoJdAJNKHlbpRfOB8vWVO4u1zQBAkqG0BEt0BfNVVlT1BhLv//SrptVE8bcF7us6 HnN0E8OZMMBWSDTZk2sRSn2jV7J481h7mbYofyllX1ySLu2uL+YHA8+160Np6Lhp t4a59O3epBSkSGrZ+LSb1KsLllVpqPoacmLb7AD3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=3rd7k9/raf/dl4SNGeF1e1iwr4qxf F77a8ztQ0GbrW0=; b=S0u0COsdPr+D4RRx8/5/pp9/b2+uZPcBkDnripZ9aak1A mVkXrJW4Lhrc/0J5jDVGJUwQKtmDYYNLMRmv09dzGL8h+6aEX1o6Ef/OK29N2dl/ sX8sUdhMsw5IVAlsxrauAdvq5Mmht2MHW84LOPupvX6ts5pCD8Quvs2hiDlumwZ7 2h4ljVDLCO2vrQael3PQ2l3tmWbuYCU/eH6/xXRlbqJE+k1QyG9aHwrUyEvaAiht OT/dSZR4JRDVboJpzCfneCrdCrUivUCdVj6g1i+YUOFmlPAlbpiKwqDIOSO+AEZ2 J+x1zLvwjZqezPnmCt9y51C7cbJ8N8Q39SDNmbW7g== X-ME-Sender: Date: Tue, 14 Nov 2017 12:26:19 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: [PATCH] don't exit shell on [[ -o invalid@option ]] Message-ID: <20171114122619.kqa4i2sth66mafrs@tarpaulin.shahaf.local2> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171112195657.74fb0b8a@ntlworld.com> User-Agent: NeoMutt/20170113 (1.7.2) Sorry for the late response; family reasons. Peter Stephenson wrote on Sun, Nov 12, 2017 at 19:56:57 +0000: > On Sat, 11 Nov 2017 15:19:05 -0800 > Bart Schaefer wrote: > > I was thinking more along the lines of tying it to EMULATION(EMULATE_SH) > > rather directly to a given option bit. So you get it if the shell is > > started as sh/ksh/etc., but you can't switch it on if started as zsh. > > This is tending to hide the knob under the sticky out bit at the top where > the logo is attached (as it were). > > Maybe we should just accept the original patch and note the > incimpatibility. It's a non-issue for properly written shell code > anyway. I wasn't sold by the OP's reasoning: Martijn Dekker wrote on Fri, Nov 10, 2017 at 18:24:29 +0000: > Does it make sense for [[ -o invalid@option ]] to exit the shell with an > error message? > Yes: "invalid@option" is neither set nor unset; it does not exist. > Other shells with '[[' (bash, ksh93 and pdksh/mksh variants) quietly > return an unsuccessful status for a non-existent shell option. That > behaviour makes more sense to me because of: > > (1) backwards compatibility: a script that uses '[[' to test if a shell > option introduced in a recent zsh is set, would still work on an older > zsh that doesn't have that shell option. > That use-case is addressable by probing ${options[schroedingerscat]} or `set -o | grep`. As Bart hinted, the proposed change is backwards *incompatible*: it makes [[ -o invalid@option ]] return 1 where currently it returns 2. (User code might be relying on the distinction between $? == 1 and $? == 2.) Moreover, if cross-version compatibility is the goal, why is it a good thing to lump "This shell does not have INVALID_OPTION" and "This shell has INVALID_OPTION and it's unset"? 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. With the current code that situation would result in a (proper) warning. I suppose we could plug the latter concern somewhat if we decided that whenever we add a new option, it'd be unset by default. > (2) cross-shell compatibility: treating a non-existent option as not set > would make it easier to write a script that works on bash, ksh93, and > pdksh/mksh as well as zsh. Devil's advocate, but why can't people just do, today, if [[ -o INVALID_OPTION ]] 2>/dev/null; then or if [[ ${options[invalidoption]:-off} == off ]]; then ? Cheers, Daniel