[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more efficient AS_EXIT
From: |
Eric Blake |
Subject: |
Re: more efficient AS_EXIT |
Date: |
Tue, 18 Nov 2008 18:56:43 -0700 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 |
-----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-----
- Re: more efficient AS_EXIT, Eric Blake, 2008/11/18
- Re: more efficient AS_EXIT, Eric Blake, 2008/11/18
- Re: more efficient AS_EXIT, Paolo Bonzini, 2008/11/19
- Re: more efficient AS_EXIT, Eric Blake, 2008/11/19
- Re: more efficient AS_EXIT, Paolo Bonzini, 2008/11/20
- Re: more efficient AS_EXIT, Eric Blake, 2008/11/20
- Re: more efficient AS_EXIT, Paolo Bonzini, 2008/11/21
- Re: more efficient AS_EXIT, Eric Blake, 2008/11/21
- Re: more efficient AS_EXIT, Ralf Wildenhues, 2008/11/22