From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9839 invoked by alias); 26 Jan 2016 22:50:12 -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: 37800 Received: (qmail 25397 invoked from network); 26 Jan 2016 22:50:11 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) 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.0 Date: Tue, 26 Jan 2016 22:50:08 +0000 From: Daniel Shahaf To: Eric Cook Cc: zsh-workers@zsh.org Subject: Re: [PATCH] typeset: set $? on incidental error Message-ID: <20160126225008.GA4731@tarsus.local2> References: <20160123235300.GC20278@tarsus.local2> <56A445E0.50706@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56A445E0.50706@gmx.com> User-Agent: Mutt/1.5.23 (2014-03-12) Eric Cook wrote on Sat, Jan 23, 2016 at 22:32:48 -0500: > 2: typeset while now part of the `language', still retains it's own exit statuses > from when it was a builtin command. ... > So in the event that typeset _and_ your arbitrary commands errors, what should $? > be set to? $? would reflect the failure of the typeset, which would shadow the failure of the command substitution. What would you expect «repeat 0+++ (exit 42)» to set $? to? repeat WORD do LIST done WORD is expanded and treated as an arithmetic expression, which must evaluate to a number N. LIST is then executed N times. repeat WORD SUBLIST This is a short form of repeat. % : $(( 0+++ )) zsh: bad math expression: lvalue required > 3: in the `real world' if you are assigning a parameter via command substitution > and there is a possibility that the command substitution could return nothing. > You would get the parameter a default value. During assignment or during expansion. > '' > typeset foo=${"$(exit 42)":-default} > # or > echo ${foo:=default} # or :- > '' "stdout is empty" is less sensitive a test than "the exit code is non-zero": for example, . zcat =(gzip << 1(again): the other shells with typeset don't behave that way, If existing typesets always exit zero in the circumstance that the patch proposes to change, no code would be broken by this change (no existing code, no new zsh-targeted code, no new ksh-targeted code), except for new ksh-targeted code written by zsh users who won't be aware of this difference. There is another such difference: SH_WORD_SPLIT. So, playing devil's advocate, we could apply the patch, provided that we document the resulting difference from other shells' 'typeset' at the same places we document that other shells have noshwordsplit by default. Thanks for the discussion; I realize the patch's chances of being accepted are slim, but I appreciate the time people take to explain why. Cheers, Daniel