Re: more efficient AS_EXIT

[Ralf Wildenhues]

* Eric Blake wrote on Wed, Nov 19, 2008 at 02:56:43AM CET:
> 
> >> address@hidden AS_SET_STATUS (@var{status})
> >> address@hidden
> >> +Emit shell code to set the value of @samp{$?} to @var{status} without
> >> +forking.
> >
> > Why guarantee that it does not fork?  But ok, I guess.
> 
> Why not?  If you take that guarantee away, then
> 
> m4_define([AS_SET_STATUS], [(exit $1)])
> 
> is sufficient (and for some shells, like dash, no slower).

Sure.  But there is no need to *codify* a QoI issue like this.
In this case, we might be able to guarantee that we never find
a shell where this doesn't work.  For a language description,
it would be completely sufficient to state:
  Emit shell code to set the value of @samp{$?} to @var{status}
  efficiently.

and that would allow for a solution on systems where problems
show up.

> According to Eric Blake on 11/18/2008 6:56 PM:
> >> Hmm.  This exposes it:
> > 
> >> $ sh -ec 'trap '\''echo $?'\'' 0; false;'
> >> 0
> > 
> >> But at the same time:
> >> $ sh -c 'set -e; trap '\''echo $?'\'' 0; false;'
> >> 1
> > 
> >> Weird.
> 
> Is it indeed the status of the command prior to the one that triggers the
> errexit?  For example, what happens on:
> 
> $ sh -ec 'trap '\''echo $?'\'' 0; : && (exit 2); echo a; : && (exit 3);
> false; echo b'

$ sh -xec 'trap '\''echo $?'\'' 0; : && (exit 2); echo a; : && (exit 3); false; 
echo b'
+ trap echo $? 0 
+ : 
+ exit 2 
+ echo 0 
0


> If it shares the pdksh bug where ': && (exit 2)' triggers errexit, even
> though it is a list and not a simple command, then the trap executes prior
> to the 'echo a', but does that result in 0 or 2?

0, unlike pdksh.

>  If it is like bash, then
> the 'echo a' will execute, but do we see 0 or 3?  Finally, if the 'echo b'
> executes, then something is seriously broken with the 'set -e' implementation.

Cheers,
Ralf