Re: Portability problems in autoconf manual

[Ralf Wildenhues]

* 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
> address@hidden 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