Hi. I am referring to the autoconf manual that I found on savannah.org under path /autoconf/manual/autoconf-2.63. Issue 1: --------- 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): $ /bin/sh -c 'trapped=0; trap "echo trapped; trapped=1" 1 2 3 15; while true; do sleep 1; if test $trapped = 1; then trap 1 2 3 15; fi; done' & [1] 1548526 $ kill -15 1548526 $ trapped $ kill -15 1548526 $ [1]+ Terminated /bin/sh -c 'trapped=0; trap "echo trapped; trapped=1" 1 2 3 15; while true; do sleep 1; if test $trapped = 1; then trap 1 2 3 15; fi; done' Issue 2: --------- 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. Regards Jens 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@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
