Re: Portability problems in autoconf manual

[Ralf Wildenhues]

* Eric Blake wrote on Wed, Jun 10, 2009 at 02:41:21PM CEST:
 According to Ralf Wildenhues on 6/8/2009 2:59 PM:
  
  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
 
 Remember, POSIX 2001 specified that you use either 0 arguments or 2 or
 more, but left the use of exactly one argument undefined.

Ah.  However, we care not about POSIX requirement, but about portability
in practice.  So, the question is how portable is the above in practice?

 $ posh -c 'trap : 0; trap; trap 0; trap; echo done'
 trap -- : EXIT
 posh: trap: no signals specified
 $ echo $?
 1
 
 But posh is already the oddball, as (depending on the version) it requires
 names instead of numbers (although I know that has already been brought up
 with the debian folks).

Look, the only reason for the existence of posh is to act as a torture
device for developers that do not write portable software.  If we have
code that is portable in practice, but fails with posh, then almost by
definition, that is a bug in posh, not in our code.  (You could even
interpret that as QoI issue in POSIX in that case.  :-)

More generally, if somebody starts using the heirloom sh as their
/bin/sh on their brand new Linux system, and then starts filing bug
reports against shell scripts that work portably on all relevant hosts,
then I'm very much inclined to not add workarounds to Autoconf, unless
there is also at least one non-museum system that exhibits the same
issues.  Moreover since the source code of those shells is available,
they should just be fixed instead.  (We should recommend to those people
to use the Autoconf testsuite as part of their shell release testing.)

  or factor the code based on whether the shell groks resetting of traps
  with a numeric first argument (and assuming it will accept '-'
  otherwise):
 
 You are on to something here.  Notice that we don't even have to worry
 about whether 0 is a command or alias, if we insist on doing things one
 trap at a time and rely on the syntax error of posh as the determining
 factor instead:
 
 if (trap 0) 2/dev/null ; then
   trap 0; trap 1; trap 2
 else
   trap - 0 1 2
 fi
 
 In my testing, this worked for Solaris /bin/sh, dash, bash, zsh, pdksh,
 and posh, modulo posh's need for signal names.  Anyone have a
 counterexample, before I publish this as a portable way to reset traps?

Haven't found any.

 Unfortunately, we cannot wrap this logic in an ease-of-use function:

Yes, we can't.

 since using trap inside a function does not properly affect the outer
 environment, on at least zsh (even with emulate sh).
 
 But we COULD make an AS_TRAP_DEFAULT macro that uses m4 expansion time to
 break a list into multiple calls as needed.

Yep.  :-)

Cheers,
Ralf

Re: Portability problems in autoconf manual

[Ralf Wildenhues]

* Eric Blake wrote on Wed, Jun 10, 2009 at 02:41:21PM CEST:
 According to Ralf Wildenhues on 6/8/2009 2:59 PM:
  
  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
 
 Remember, POSIX 2001 specified that you use either 0 arguments or 2 or
 more, but left the use of exactly one argument undefined.

Ah.  However, we care not about POSIX requirement, but about portability
in practice.  So, the question is how portable is the above in practice?

 $ posh -c 'trap : 0; trap; trap 0; trap; echo done'
 trap -- : EXIT
 posh: trap: no signals specified
 $ echo $?
 1
 
 But posh is already the oddball, as (depending on the version) it requires
 names instead of numbers (although I know that has already been brought up
 with the debian folks).

Look, the only reason for the existence of posh is to act as a torture
device for developers that do not write portable software.  If we have
code that is portable in practice, but fails with posh, then almost by
definition, that is a bug in posh, not in our code.  (You could even
interpret that as QoI issue in POSIX in that case.  :-)

More generally, if somebody starts using the heirloom sh as their
/bin/sh on their brand new Linux system, and then starts filing bug
reports against shell scripts that work portably on all relevant hosts,
then I'm very much inclined to not add workarounds to Autoconf, unless
there is also at least one non-museum system that exhibits the same
issues.  Moreover since the source code of those shells is available,
they should just be fixed instead.  (We should recommend to those people
to use the Autoconf testsuite as part of their shell release testing.)

  or factor the code based on whether the shell groks resetting of traps
  with a numeric first argument (and assuming it will accept '-'
  otherwise):
 
 You are on to something here.  Notice that we don't even have to worry
 about whether 0 is a command or alias, if we insist on doing things one
 trap at a time and rely on the syntax error of posh as the determining
 factor instead:
 
 if (trap 0) 2/dev/null ; then
   trap 0; trap 1; trap 2
 else
   trap - 0 1 2
 fi
 
 In my testing, this worked for Solaris /bin/sh, dash, bash, zsh, pdksh,
 and posh, modulo posh's need for signal names.  Anyone have a
 counterexample, before I publish this as a portable way to reset traps?

Haven't found any.

 Unfortunately, we cannot wrap this logic in an ease-of-use function:

Yes, we can't.

 since using trap inside a function does not properly affect the outer
 environment, on at least zsh (even with emulate sh).
 
 But we COULD make an AS_TRAP_DEFAULT macro that uses m4 expansion time to
 break a list into multiple calls as needed.

Yep.  :-)

Cheers,
Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Portability problems in autoconf manual

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 6/8/2009 2:59 PM:
 
 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

Remember, POSIX 2001 specified that you use either 0 arguments or 2 or
more, but left the use of exactly one argument undefined.  Only POSIX 2008
introduced the possibility of a syntactically valid use of exactly 1
argument.  But you are certainly on to something; it looks like dash does
indeed recognize a 1-argument trap call as a reset:

$ dash -c 'trap echo 0; trap; trap 0; trap; echo done'
trap -- 'echo' EXIT
done
$

As do most other shells that I tested: Solaris /bin/sh, bash, zsh, pdksh,
ash.  However, I did find an exception:

$ posh -c 'trap : 0; trap; trap 0; trap; echo done'
trap -- : EXIT
posh: trap: no signals specified
$ echo $?
1

But posh is already the oddball, as (depending on the version) it requires
names instead of numbers (although I know that has already been brought up
with the debian folks).

 or factor the code based on whether the shell groks resetting of traps
 with a numeric first argument (and assuming it will accept '-'
 otherwise):

You are on to something here.  Notice that we don't even have to worry
about whether 0 is a command or alias, if we insist on doing things one
trap at a time and rely on the syntax error of posh as the determining
factor instead:

if (trap 0) 2/dev/null ; then
  trap 0; trap 1; trap 2
else
  trap - 0 1 2
fi

In my testing, this worked for Solaris /bin/sh, dash, bash, zsh, pdksh,
and posh, modulo posh's need for signal names.  Anyone have a
counterexample, before I publish this as a portable way to reset traps?

Unfortunately, we cannot wrap this logic in an ease-of-use function:

# trap_default TRAP[...]
# --
# For each TRAP number, reset the trap to its default state.
if (trap 0) 2/dev/null ; then
trap_default()
{
  for num
  do
trap $num
  done
}
else
trap_default()
{
  trap - $*
}
fi

since using trap inside a function does not properly affect the outer
environment, on at least zsh (even with emulate sh).

But we COULD make an AS_TRAP_DEFAULT macro that uses m4 expansion time to
break a list into multiple calls as needed.

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

Eric Blake e...@byu.net
-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

iEYEARECAAYFAkovqfEACgkQ84KuGfSFAYDxQACaA4O1DxGKKUMYcoQeUvhuG1Ov
Oq0AoMS5+smpn0T/9NAF4g+wrznWw57N
=8Iz9
-END PGP SIGNATURE-

Re: Portability problems in autoconf manual

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 6/8/2009 2:59 PM:
 
 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

Remember, POSIX 2001 specified that you use either 0 arguments or 2 or
more, but left the use of exactly one argument undefined.  Only POSIX 2008
introduced the possibility of a syntactically valid use of exactly 1
argument.  But you are certainly on to something; it looks like dash does
indeed recognize a 1-argument trap call as a reset:

$ dash -c 'trap echo 0; trap; trap 0; trap; echo done'
trap -- 'echo' EXIT
done
$

As do most other shells that I tested: Solaris /bin/sh, bash, zsh, pdksh,
ash.  However, I did find an exception:

$ posh -c 'trap : 0; trap; trap 0; trap; echo done'
trap -- : EXIT
posh: trap: no signals specified
$ echo $?
1

But posh is already the oddball, as (depending on the version) it requires
names instead of numbers (although I know that has already been brought up
with the debian folks).

 or factor the code based on whether the shell groks resetting of traps
 with a numeric first argument (and assuming it will accept '-'
 otherwise):

You are on to something here.  Notice that we don't even have to worry
about whether 0 is a command or alias, if we insist on doing things one
trap at a time and rely on the syntax error of posh as the determining
factor instead:

if (trap 0) 2/dev/null ; then
  trap 0; trap 1; trap 2
else
  trap - 0 1 2
fi

In my testing, this worked for Solaris /bin/sh, dash, bash, zsh, pdksh,
and posh, modulo posh's need for signal names.  Anyone have a
counterexample, before I publish this as a portable way to reset traps?

Unfortunately, we cannot wrap this logic in an ease-of-use function:

# trap_default TRAP[...]
# --
# For each TRAP number, reset the trap to its default state.
if (trap 0) 2/dev/null ; then
trap_default()
{
  for num
  do
trap $num
  done
}
else
trap_default()
{
  trap - $*
}
fi

since using trap inside a function does not properly affect the outer
environment, on at least zsh (even with emulate sh).

But we COULD make an AS_TRAP_DEFAULT macro that uses m4 expansion time to
break a list into multiple calls as needed.

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

Eric Blake e...@byu.net
-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

iEYEARECAAYFAkovqfEACgkQ84KuGfSFAYDxQACaA4O1DxGKKUMYcoQeUvhuG1Ov
Oq0AoMS5+smpn0T/9NAF4g+wrznWw57N
=8Iz9
-END PGP SIGNATURE-


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

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
 +...@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) 21`; 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) 21`; then

Which shells are missing out on this?

Thanks!
Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Portability problems in autoconf manual

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[moving to autoconf-patches, replies can drop autoconf]

According to jens.schmid...@arcor.de on 4/29/2009 3:40 AM:
 Hi.

Hi Jens, and sorry it has taken me so long to respond to your suggestions.

 There it says in section Limitation of Shell Builtins:
 
   Posix says that ‘trap - 1 2 13 15’ resets the traps for the specified 
 signals to
   their default values, but many common shells (e.g., Solaris /bin/sh) 
 misinterpret
   this and attempt to execute a “command” named - when the specified 
   conditions arise. There is no portable workaround, except for ‘trap - 0’, 
 for
   which ‘trap ’’ 0’ is a portable substitute.
 
 I do not entirely agree with the latter statement.  It seems that 'trap 1 2 
 13 15' (without any command) reset the traps in a reasonably portable way, as 
 documented also in the sh man pages. I tested the following on AIX, HP-UX 
 (SPARC  x86-64), HP-UX (PA-RISC  IA64), Tru64, Linux (x86, x86-64, IA64, 
 PPC) (yes, I wanted to show off a bit):

As was pointed out in the thread, POSIX 2008 requires this behavior, but
it is not yet portable (at least dash fails this, so your tests were not
exhaustive).

 
 On Solaris 9, /bin/sh does not execute a trap on exit if in a parenthesised 
 sub-shell if the last command is not a built-in:
 
   $ ( trap echo foo 0; :; true )
   $ ( trap echo foo 0; true; : )
   foo
 
 Of course, the error diagnosis may not entirely precise. Better it would be 
 to say: On Solaris 9, /bin/sh may not execute a trap on exit if the trap is 
 defined in a parenthesised sub-shell.
 
 A workaround may be to always exit explicitly with exit $? from the 
 sub-shell.

I added an example of this.

 Another reason to be careful with set -e on Solaris 10: A failing command 
 substitution may not be caught by any means if option -e is set. The shell 
 bails out immediately:
 
   $ ( set -e; foo=`false` || echo foo; echo bar ); echo baz
   baz

I've mentioned this.

 Older Bashes (mine is 2.05b.0(1)) may forget exit values if there is a trap 
 on exit set and if the trap consists of one succeeding external command only. 
  Seems to be fixed in latest Bashes.
 
   $ /bin/bash -c 'trap /bin/true 0; exit 2'; echo $?
   0
   $ /bin/bash -c 'trap :; /bin/true 0; exit 2'; echo $?
   2
 
 I hit that problem when I had a rm -f  clean-up trap in a canned sequence 
 in a makefile, where the sequence failed but make did not take any notice 
 of that fact due to this bug ... not too exotic an use-case, I think.

Also good to mention, especially since it has a workaround.

Here's what I'm applying:

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

Eric Blake e...@byu.net
-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

iEYEARECAAYFAkorPLAACgkQ84KuGfSFAYDuQgCggTpzobCv65JWsgjVDi1s6K/l
WSEAoMOysv7aSF03/Mh2Cz/LyTh5/R8F
=uHHh
-END PGP SIGNATURE-
From 16a04c38e16cfb451bdfe561d2856068aa28c2a2 Mon Sep 17 00:00:00 2001
From: Eric Blake e...@byu.net
Date: Sat, 6 Jun 2009 22:03:16 -0600
Subject: [PATCH] Improve documentation on trap pitfalls.

* doc/autoconf.texi (Limitations of Builtins) trap: Mention new
Posix 2008 requirement on trap, and dash bug in implementing it.
Mention various shell bugs with traps defined inside subshells.
Mention older bash limitation with single-command exit trap.
set: Mention another 'set -e' limitation.
Reported by Jens Schmidt.

Signed-off-by: Eric Blake e...@byu.net
---
 ChangeLog |8 
 doc/autoconf.texi |   41 -
 2 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 9a7ccf7..a9bd462 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2009-06-06  Eric Blake  e...@byu.net

+   Improve documentation on trap pitfalls.
+   * doc/autoconf.texi (Limitations of Builtins) trap: Mention new
+   Posix 2008 requirement on trap, and dash bug in implementing it.
+   Mention various shell bugs with traps defined inside subshells.
+   Mention older bash limitation with single-command exit trap.
+   set: Mention another 'set -e' limitation.
+   Reported by Jens Schmidt.
+
Avoid ambiguous fallback in AC_PROG_CXX, AC_PROG_OBJC.
* lib/autoconf/c.m4 (AC_PROG_CXX, AC_PROG_OBJC): Use 'no', rather
than an ambiguous compiler name, when no compiler is present.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 215c864..81bce07 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -16188,6 +16188,16 @@ Limitations of Builtins
 $foo; then exit 1; fi} rather than @samp{test -n $foo  exit 1}.
 Another possibility is to warn @acronym{BSD} users not to use @samp{sh -e}.

+When @samp{set -e} is in effect, a failed command substitution in
+Solaris @command{/bin/sh} cannot be ignored, even with @samp{||}.
+
+...@example
+$ 

Re: Portability problems in autoconf manual

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[moving to autoconf-patches, replies can drop autoconf]

According to jens.schmid...@arcor.de on 4/29/2009 3:40 AM:
 Hi.

Hi Jens, and sorry it has taken me so long to respond to your suggestions.

 There it says in section Limitation of Shell Builtins:
 
   Posix says that ‘trap - 1 2 13 15’ resets the traps for the specified 
 signals to
   their default values, but many common shells (e.g., Solaris /bin/sh) 
 misinterpret
   this and attempt to execute a “command” named - when the specified 
   conditions arise. There is no portable workaround, except for ‘trap - 0’, 
 for
   which ‘trap ’’ 0’ is a portable substitute.
 
 I do not entirely agree with the latter statement.  It seems that 'trap 1 2 
 13 15' (without any command) reset the traps in a reasonably portable way, as 
 documented also in the sh man pages. I tested the following on AIX, HP-UX 
 (SPARC  x86-64), HP-UX (PA-RISC  IA64), Tru64, Linux (x86, x86-64, IA64, 
 PPC) (yes, I wanted to show off a bit):

As was pointed out in the thread, POSIX 2008 requires this behavior, but
it is not yet portable (at least dash fails this, so your tests were not
exhaustive).

 
 On Solaris 9, /bin/sh does not execute a trap on exit if in a parenthesised 
 sub-shell if the last command is not a built-in:
 
   $ ( trap echo foo 0; :; true )
   $ ( trap echo foo 0; true; : )
   foo
 
 Of course, the error diagnosis may not entirely precise. Better it would be 
 to say: On Solaris 9, /bin/sh may not execute a trap on exit if the trap is 
 defined in a parenthesised sub-shell.
 
 A workaround may be to always exit explicitly with exit $? from the 
 sub-shell.

I added an example of this.

 Another reason to be careful with set -e on Solaris 10: A failing command 
 substitution may not be caught by any means if option -e is set. The shell 
 bails out immediately:
 
   $ ( set -e; foo=`false` || echo foo; echo bar ); echo baz
   baz

I've mentioned this.

 Older Bashes (mine is 2.05b.0(1)) may forget exit values if there is a trap 
 on exit set and if the trap consists of one succeeding external command only. 
  Seems to be fixed in latest Bashes.
 
   $ /bin/bash -c 'trap /bin/true 0; exit 2'; echo $?
   0
   $ /bin/bash -c 'trap :; /bin/true 0; exit 2'; echo $?
   2
 
 I hit that problem when I had a rm -f  clean-up trap in a canned sequence 
 in a makefile, where the sequence failed but make did not take any notice 
 of that fact due to this bug ... not too exotic an use-case, I think.

Also good to mention, especially since it has a workaround.

Here's what I'm applying:

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

Eric Blake e...@byu.net
-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

iEYEARECAAYFAkorPLAACgkQ84KuGfSFAYDuQgCggTpzobCv65JWsgjVDi1s6K/l
WSEAoMOysv7aSF03/Mh2Cz/LyTh5/R8F
=uHHh
-END PGP SIGNATURE-
From 16a04c38e16cfb451bdfe561d2856068aa28c2a2 Mon Sep 17 00:00:00 2001
From: Eric Blake e...@byu.net
Date: Sat, 6 Jun 2009 22:03:16 -0600
Subject: [PATCH] Improve documentation on trap pitfalls.

* doc/autoconf.texi (Limitations of Builtins) trap: Mention new
Posix 2008 requirement on trap, and dash bug in implementing it.
Mention various shell bugs with traps defined inside subshells.
Mention older bash limitation with single-command exit trap.
set: Mention another 'set -e' limitation.
Reported by Jens Schmidt.

Signed-off-by: Eric Blake e...@byu.net
---
 ChangeLog |8 
 doc/autoconf.texi |   41 -
 2 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 9a7ccf7..a9bd462 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2009-06-06  Eric Blake  e...@byu.net

+   Improve documentation on trap pitfalls.
+   * doc/autoconf.texi (Limitations of Builtins) trap: Mention new
+   Posix 2008 requirement on trap, and dash bug in implementing it.
+   Mention various shell bugs with traps defined inside subshells.
+   Mention older bash limitation with single-command exit trap.
+   set: Mention another 'set -e' limitation.
+   Reported by Jens Schmidt.
+
Avoid ambiguous fallback in AC_PROG_CXX, AC_PROG_OBJC.
* lib/autoconf/c.m4 (AC_PROG_CXX, AC_PROG_OBJC): Use 'no', rather
than an ambiguous compiler name, when no compiler is present.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 215c864..81bce07 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -16188,6 +16188,16 @@ Limitations of Builtins
 $foo; then exit 1; fi} rather than @samp{test -n $foo  exit 1}.
 Another possibility is to warn @acronym{BSD} users not to use @samp{sh -e}.

+When @samp{set -e} is in effect, a failed command substitution in
+Solaris @command{/bin/sh} cannot be ignored, even with @samp{||}.
+
+...@example
+$ 

Aw: Re: Portability problems in autoconf manual

[jens . schmidt35]

 On Wednesday 29 April 2009 16:22:08 Andreas Schwab wrote:
  Mike Frysinger vap...@gentoo.org writes:
  
 http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#t
  rap If the first operand is an unsigned decimal integer, the shell shall
   treat all operands as conditions, and shall reset each condition to the
   default value. Otherwise, if there are operands, the first is treated
 as
   an action and the remaining as conditions.
 
  This paragraph is new in POSIX.1-2008.
 
 still makes dash broken, but makes it much less useful in the portability 
 document since we're looking at supporting systems much older than 2008

But it seems that not only the newest POSIX standard mandates
such behaviour, but also that most existing shells behave like
that.

In any case, I would find it worth mentioning in the autoconf
documentation, where it says that there is no portable
work-around to trap - 1 2 3 15, that there is a
mostly portable alternative. This wouldn't be the first
incident of such a statement in the document.


Arcor.de Gaming Area - kostenfrei daddeln bis der Arzt kommt!
Jetzt checken und aus über 80 Spielen wählen!
http://www.arcor.de/footer-gaming/


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Portability problems in autoconf manual

[Paul Eggert]

It seems that 'trap 1 2 13 15' (without any command) reset the traps 
in a reasonably portable way,


I'm afraid not.  For example, on Ubuntu 9.04:

$ dash
!-penguin $ trap 1 2
!-penguin $ kill -2 $$
dash: 1: not found

It's hard to argue that this is a bug, since POSIX requires this behavior.

 Better it would be to say: On Solaris 9, /bin/sh may not execute a 
trap on exit if the trap is defined in a parenthesised sub-shell.



Yes, that sounds more accurate.


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Portability problems in autoconf manual

[Mike Frysinger]

On Wednesday 29 April 2009 15:47:19 Paul Eggert wrote:
  It seems that 'trap 1 2 13 15' (without any command) reset the traps
  in a reasonably portable way,

 I'm afraid not.  For example, on Ubuntu 9.04:

 $ dash
 !-penguin $ trap 1 2
 !-penguin $ kill -2 $$
 dash: 1: not found

 It's hard to argue that this is a bug, since POSIX requires this behavior.

that looks like a bug in dash according to the POSIX documentation

http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap
If the first operand is an unsigned decimal integer, the shell shall treat all 
operands as conditions, and shall reset each condition to the default value. 
Otherwise, if there are operands, the first is treated as an action and the 
remaining as conditions.

thus `trap 1 2` should reset signals 1 and 2 to the default handler since the 
first arg 1 is an unsigned decimal integer.
-mike


signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Portability problems in autoconf manual

[Andreas Schwab]

Mike Frysinger vap...@gentoo.org writes:

 http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap
 If the first operand is an unsigned decimal integer, the shell shall treat 
 all 
 operands as conditions, and shall reset each condition to the default value. 
 Otherwise, if there are operands, the first is treated as an action and the 
 remaining as conditions.

This paragraph is new in POSIX.1-2008.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Portability problems in autoconf manual

[Mike Frysinger]

On Wednesday 29 April 2009 16:22:08 Andreas Schwab wrote:
 Mike Frysinger vap...@gentoo.org writes:
  http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#t
 rap If the first operand is an unsigned decimal integer, the shell shall
  treat all operands as conditions, and shall reset each condition to the
  default value. Otherwise, if there are operands, the first is treated as
  an action and the remaining as conditions.

 This paragraph is new in POSIX.1-2008.

still makes dash broken, but makes it much less useful in the portability 
document since we're looking at supporting systems much older than 2008
-mike


signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Portability problems in autoconf manual

[Ralf Wildenhues]

Hello,

* Paul Eggert wrote on Wed, Apr 29, 2009 at 09:47:19PM CEST:
[
  $ ( trap echo foo 0; :; true )
  $ ( trap echo foo 0; true; : )
  foo
]

  Better it would be to say: On Solaris 9, /bin/sh may not execute a  
 trap on exit if the trap is defined in a parenthesised sub-shell.

 Yes, that sounds more accurate.

Happens on Solaris 10 as well.  With zsh 4.3.6 (on several systems),
even in emulate sh mode, none of the above produced output, neither
when true is replaced by a non-builtin.  Neither with bsh on AIX 5.3,
but of course nobody uses bsh.  Neither with /bin/sh on Tru64.

Cheers,
Ralf


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf

Re: Portability problems in autoconf manual

[Paul Eggert]

It seems that 'trap 1 2 13 15' (without any command) reset the traps 
in a reasonably portable way,


I'm afraid not.  For example, on Ubuntu 9.04:

$ dash
!-penguin $ trap 1 2
!-penguin $ kill -2 $$
dash: 1: not found

It's hard to argue that this is a bug, since POSIX requires this behavior.

 Better it would be to say: On Solaris 9, /bin/sh may not execute a 
trap on exit if the trap is defined in a parenthesised sub-shell.



Yes, that sounds more accurate.