From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19231 invoked by alias); 20 Nov 2017 01:22:59 -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: 42039 Received: (qmail 16902 invoked by uid 1010); 20 Nov 2017 01:22:59 -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 13.432224 secs); 20 Nov 2017 01:22:59 -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-transfer-encoding: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=53PRlI HKStcSH9HoA/A7WLlJCn8Gyg+gNMXsUmsvoI8=; b=VXt2f1blZ0dXz/NR0CsW8Q 0Dtjw2T5cUsm47IFQ+czVpO22AeENpkJyYxe7xWkcnP/dZfK4WzQYLx19DKNnuAb sVPBZOlwVGjUBuhO9ifvDApbWjtqFDLEkyJ7a2SpW+a4yV9BobWPNqrc9Cr5lu40 RW+3ddk3IFhVVV+xIrosgu+MYKs91HB60E015hoffgRuEIC0Df6Pa96siDumZHQx KLXzEoNXfswVR14FBso6ancARu5k1rkRsi223VXhoSt9vXf3o9BPOb5R8c7eibfY 88DrmXtn4wmsaXMd15bdByQxb3eE6YDpOYwNdsAN/GuM9SOVn5S09qfc1ZMSsolA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=53PRlI HKStcSH9HoA/A7WLlJCn8Gyg+gNMXsUmsvoI8=; b=iOcLD9GmjiDvrkdjcIcu7n 5axuZxyE1lDTSnaQXjqRVSEyJKa+3oZEnhkrpK6NXLdZtQhbcMvQLMd41iHM5s6u 3JkicBl8FKv8htNkCLmCacnjW0u98NYmrK89C+38kYdLER4pniWiJTkNPvyfxL8I +144v2WzKFtkFyBxgu1pRO2qUKmtN2Hm43KSOXvqt7JJFMskHPSEegWjjaaqcPR4 WqaYuhedD8ZTJ1KE0rMKDbvyck98UndVuppn+BMNf4nF8XSImnBdBXP+CCsWyjO0 slI10/3lrjH2lZChw8dBTDKU4P04FgImOYqNpJJHb4YTRlvQW045agiUYHSsPfHg == X-ME-Sender: Message-Id: <1511140961.722411.1177910864.7ECFDEB6@webmail.messagingengine.com> From: Daniel Shahaf To: zsh-workers@zsh.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4ef04c51 In-Reply-To: <20171119195337.0a09b303@ntlworld.com> Subject: Re: [PATCH] don't exit shell on [[ -o invalid@option ]] Date: Mon, 20 Nov 2017 01:22:41 +0000 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> <1511029379.709069.1176966800.1BF7416A@webmail.messagingengine.com> <20171119195337.0a09b303@ntlworld.com> Peter Stephenson wrote on Sun, 19 Nov 2017 19:53 +0000: > On Sun, 19 Nov 2017 11:41:57 -0800 > Bart Schaefer wrote: > > On Sat, Nov 18, 2017 at 10:22 AM, Daniel Shahaf wrote: > > > > > > How about the following. > > > > > > It uses status 3 because status 2 currently means "syntax error in [[" > > > and I didn't want to overload that; and it uses POSIX_BUILTINS because > > > that seemed more closely related than POSIX_IDENTIFIERS. > > > > For reasons I can't entirely define, it bothers me that an operation > > to test the setting of options changes its behavior based on the > > setting of an option. > Are you concerned about self-reference? I.e., that code meant to run under any options (example: z-sy-h) wouldn't be able to test the settedness of an option using [[ -o foo ]] because the behaviour of that command depends on whether foo is set? (That's basically the Liar Paradox) I don't think that's a problem in this case, but I'm listening... > I'm actually more worried if this *isn't* an option, given it's (in a > more touchy feely sense) optional behaviour. Having something of that > kind based on emulation seems a bit gross. But we do have gross syntax > changes based on emulation, it's true, such as variables that never > appear. I'm quite swamped this week (in a good way) but when I get a chance I'll finish the patch and push. (Needs more tests and a README blurb, at least) Cheers, Daniel