* 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;
* 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;
-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
-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
* 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
-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
-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
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
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.
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
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
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
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
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.
14 matches
Mail list logo
