Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] typeset: set $? on incidental error
- X-seq: zsh-workers 37800
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: Eric Cook <llua@xxxxxxx>
- Subject: Re: [PATCH] typeset: set $? on incidental error
- Date: Tue, 26 Jan 2016 22:50:08 +0000
- Cc: zsh-workers@xxxxxxx
- In-reply-to: <56A445E0.50706@gmx.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20160123235300.GC20278@tarsus.local2> <56A445E0.50706@gmx.com>
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 <<<foo; gzip <<<bar | perl -pe 's/\x08/\xff/')
.
is caught by the latter but not by the former.
> 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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author