[FYI 2/2] {test-protocols} tap/awk: account for unusual korn shell signal handling behaviour

2011-09-28 Thread Stefano Lattarini
Log +++ b/ChangeLog @@ -1,5 +1,16 @@ 2011-09-28 Stefano Lattarini + tap/awk: account for unusual korn shell signal handling behaviour + This change has been motivated by a testsuite failure on Debian + with the AT&T Korn Shell version 93u-1. + * lib/tap-driver.sh: Tempo

[FYI 0/2] {test-protocols} More fixes for unusual signal handling behaviour of Korn Shells.

2011-09-28 Thread Stefano Lattarini
Stefano Lattarini (2): tap/awk: handle exit statuses > 256 (seen on few korn shells) tap/awk: account for unusual korn shell signal handling behaviour ChangeLog | 24 lib/tap-driver.sh | 29 + 2 files changed, 49 inserti

[FYI 1/4] {testsuite-work} test defs: work around weird ksh behaviour w.r.t. signal handling

2011-09-13 Thread Stefano Lattarini
eLog index 9b98bfd..cbc6693 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,14 @@ +2011-09-13 Stefano Lattarini + + test defs: work around weird ksh behaviour w.r.t. signal handling + * tests/defs (is_blocked_signal): Use perl to determine whether a + signal is trapped, sin

Re: signal handling

2007-11-18 Thread Ralf Wildenhues
* Ralf Wildenhues wrote on Tue, Nov 13, 2007 at 12:08:28AM CET: > * Bob Proulx wrote on Mon, Nov 12, 2007 at 10:52:45PM CET: > > Ralf Wildenhues wrote: > > > Ahh. More head scratching. I'd appreciate if somebody could > > > look over these two proposed patches to see if what I think how > > > sig

Re: signal handling

2007-11-12 Thread Ralf Wildenhues
* Bob Proulx wrote on Mon, Nov 12, 2007 at 10:52:45PM CET: > Ralf Wildenhues wrote: > > Ahh. More head scratching. I'd appreciate if somebody could > > look over these two proposed patches to see if what I think how > > signals ought to work makes sense. > > This one I think is the opposite of w

Re: signal handling

2007-11-12 Thread Bob Proulx
Ralf Wildenhues wrote: > Ahh. More head scratching. I'd appreciate if somebody could > look over these two proposed patches to see if what I think how > signals ought to work makes sense. This one I think is the opposite of what it needs to be. > +trap '' $signal I think that should be in

signal handling (was: prepare Automake's test suite for parallelization)

2007-11-12 Thread Ralf Wildenhues
cleanup of third-party TESTS users into Automake: they may want to handle interrupts in their suite, and we certainly should not interfere with that. Fix signal handling in the Automake test suite. * tests/defs.in: If the trap was invoked by a signal, then reraise the signal after cl