-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Ralf Wildenhues on 11/16/2008 7:43 AM: > Signal and job handling in shell is a portability disaster. Sigh. > Apologies for not providing a series of small patches, but it didn't > really fit well with the topic.
Thanks for tackling this. > > Now, I don't think we can get all of (1-7) in a portable fashion. > Let's concentrate first on getting things to work on a common system > (say, Bash 3.2 on GNU/Linux, GNU make), and then work to make things > portable. As a last measure, turning off parallel execution may be > one measure to avoid breakage on less capable systems, iff supporting > them is too much hassles otherwise. As there are already other parallel issues (think cygwin's fifo implementation), I tend to agree that it is okay to disable parallel testing and fall back to reliable serial testing on platforms where we can't make parallel testing handle signals properly. But we can sure try to get parallel working first, especially for the common case of GNU/Linux and a decent shell. > Kudos to R. Stevens, by the way. Does he need mention in the changelog? > +dnl So what we do is enable shell job control if available, which causes the > +dnl shell to start each parallel task as its own shell job, thus as a new > +dnl process group leader. We then send the signal to all new process groups. It sounds like if the shell doesn't support job control, then we should not allow parallel tests? > +for at_signal in 1 2 15; do > +dnl This signal handler is not suitable for PIPE: it causes writes. > +dnl The code that was interrupted may have the errexit, monitor, or xtrace > +dnl flags enabled, so sanitize. > + trap 'set +e +x For portability to shells that only see options in the first argument to set, shouldn't this use 'set +ex'? > + AS_WARN([caught signal $at_signal, bailing out]) Is there any portable way to list the signal by name, not just number? > +dnl Unfortunately, ksh93 fork-bombs when we send TSTP, so send STOP > +dnl if this might be ksh (STOP prevents possible TSTP handlers inside > +dnl AT_CHECKs from running). Then stop ourselves. > + at_sig=TSTP > + test "${TMOUT+set}" = set && at_sig=STOP Using the very same idea you questioned earlier. Is there any way to more reliably detect ksh than whether TMOUT is set? Does this still work in bash/zsh if TMOUT was exported? > + kill -$at_sig $at_pids 2>/dev/null Is 'kill -TSTP' or 'kill -STOP' portable? Or do we have to fall back to numeric arguments (for that matter, TSTP and STOP don't always map to the same signal numbers). > +dnl We got a CONT, so let's go again. Passing this to all processes > +dnl in the groups is necessary (because we stopped them), but it may > +dnl cause changed test semantics; e.g., a sleep will be interrupted. > + test -z "$at_pids" || kill -CONT $at_pids 2>/dev/null' TSTP What do we do about shells, like ash, that choke on "trap ... TSTP"? $ ash -c 'trap "" TSTP' trap: bad signal TSTP > + trap 'set +x +e Again, shouldn't this be 'set +xe'? > + # We'd like to check this here, too, but some shells do now allow to > + # turn off job control. s/now/not/ > +# Apparently some shells don't get around to creating 'status' any more. > +# And ksh93 on FreeBSD uses 256 + 13 instead of 128 + 13 That's screwy (since exit status is supposed to be 8 bits). As a separate patch, can you please prepare a documentation patch for all the gotcha's that you have discovered during this exercise, such as FreeBSD's broken exit status? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----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 iEYEARECAAYFAkkgj3oACgkQ84KuGfSFAYBrCwCg1ZmTSghT68j0oIC17dVCnukO TkkAoIr9jE2Dgi2CIhUjjmqjrxKtZFx6 =IVIu -----END PGP SIGNATURE-----