Re: more efficient AS_EXIT

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 11/18/2008 2:18 PM:
>> address@hidden
>> +$ @kbd{bash -c 'trap '\''echo $?'\'' 0; set -e; false'}
>> +1
>> +$ @kbd{sh -c 'trap '\''echo $?'\'' 0; set -e; false'}
>> +0
> 
> This isn't correct.  Even Tru64 sh will echo 1 in this case.

Thanks for the additional research (I don't have personal access to a
Tru64 machine).  I'll update the docs accordingly, unless you beat me.

> 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.

Weird indeed.  Enough so that making the example be just these two lines
is a good way to point out how pointless it is to try to rely on 'set -e'
in a portable script.

>> mechanical replacement to the shorter a[cst]_fn_ for shell functions,
>
> OK with me, but please do not name functions outside a[cst]_fn_.  That
> allows us to remember mechanically that there are shells which do not
> provide separate namespaces for functions and variables.

Agreed.

>
> Hmm.  How about 'append @samp{|| AS_EXIT}' and make AS_EXIT use
> m4_default([$1], [$?])?  Current documented default is 1, and a couple
> of places in Autoconf exploit that, but I wonder whether $? would be a
> more consistent one: that's the default of `exit' (except for
> portability warts).

Well, as AS_EXIT was previously undocumented, I am comfortable making that
change.  It does seem like making $? instead of 1 is a better default,
even if it might make some scripts in the wild start returning 0.

>> 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).

>
>>  However, this is not guaranteed to abort a shell running with
>> address@hidden -e} (@pxref{Limitations of Builtins, , Limitations of Shell
>> +Builtins}).
>
> I still wonder whether this can be worked around (or is that overkill?).

I'm not sure.  I first thought of:

as_fn_set_status ()
{
  case $1_$- in #(
    0_*e*) return 0 ;; #(
    *e*) exit $1 ;; #(
    *) return $1 ;;
  esac
}

The idea being that if the function for AS_SET_STATUS would have returned
non-zero status, but 'set -e' is in effect, then we might as well exit now
rather than waiting for a possibly broken errexit that might not kick in.

But that only helps as_fn_set_status; what about other shell functions?  I
also thought of:

AS_SET_STATUS([1]) || echo $?

which, being more than a simple command, must not trigger an errexit
condition.  So far, the only shell identified so far that has this bug is
Solaris /bin/sh, and since Solaris always ships with a better shell, maybe
it would be as simple as adding a clause to _AS_DETECT_SUGGESTED that will
reject /bin/sh in favor of at least /usr/xpg4/bin/sh.  But at this point,
I'm not too worried about just letting the documentation warning stay in
place, without trying to avoid the /bin/sh wart.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkjcloACgkQ84KuGfSFAYC0QQCgoE3++qNq5DQ4rie+Llf0ho5Z
Xo4An1XC9qGeczrZIup8Mt8o59h7yNvg
=eQ85
-----END PGP SIGNATURE-----