* Eric Blake wrote on Sun, Jun 07, 2009 at 06:06:08AM CEST:
> [moving to autoconf-patches, replies can drop autoconf]
Hmm, it's good to have input from the experience of others on this.
> @@ -16345,7 +16355,11 @@ Limitations of Builtins
> specified signals to their default values, but many common shells (e.g.,
> Solaris @command{/bin/sh}) misinterpret this and attempt to execute a
> ``command'' named @command{-} when the specified conditions arise.
> -There is no portable workaround, except for @samp{trap - 0}, for which
> +Posix 2008 also added a requirement to support @samp{trap 1 2 13 15} to
> +reset traps, as this is supported by a larger set of shells, but there
> +are still shells like @command{dash} that mistakenly try to execute
> +@command{1} instead of resetting the traps. Therefore, there is no
> +portable workaround, except for @samp{trap - 0}, for which
> @samp{trap '' 0} is a portable substitute.
If I understand this correctly, then there are one, or even two ways to
portably reset traps to their default value: either use reset only one
signal at a time:
trap 1; trap 2; trap 13; trap 15
or factor the code based on whether the shell groks resetting of traps
with a numeric first argument (and assuming it will accept '-'
otherwise):
trap_default=trap
if test -n "`(trap 0 0; exit) 2>&1`"; then
trap_default='trap -'
fi
$trap_default 1 2 13 15
The snippet might want to avoid hitting an alias or executable named '0'
by using something like this instead:
if test -n "`(alias 0='echo nope'; trap 0 0; exit) 2>&1`"; then
Which shells are missing out on this?
Thanks!
Ralf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
