Hi! ----
[More or less a follow-up to the original "ksh93 eats signals" thread] I spend some more time testing the signal handing in ksh93 and remebered that ksh93 does not call |fork()| for subshells unless it becomes unavoidable, for example if an user likes to define process limits using the "ulimit" builtin. Testing a simple "ulimit -c 0" injected in the test line seems to reveal a couple of issues: 1. Force |fork()| in a subshell after an user sets a user trap for SIGSUR1: -- snip -- $ ksh -c 'printf "#PID=%d\n" $$ ; trap "echo l1_SIGUSR1 ; exit 0" USR1 ; (trap "echo l2_SIGUSR1 ; exit 0" USR1 ; ulimit -c 0 ; exec kill -USR1 $$ & wait) ; print "#done."' #PID=1623 #done. -- snip -- In this case the user's "trap" function never gets called. 2. Force |fork()| in a subshell after entering the subshell but before an user sets a user trap for SIGSUR1: -- snip -- $ ksh93 -c 'printf "#PID=%d\n" $$ ; trap "echo l1_SIGUSR1 ; exit 0" USR1 ; (ulimit -c 0 ; trap "echo l2_SIGUSR1 ; exit 0" USR1 ; exec kill -USR1 $$ & wait) ; print "#done."' #PID=1641 User signal 1 -- snip -- In this case the system's default handler for SIGUSR1 gets invoked instead of the user's "trap" function. For comparisation the expected output looks like this: -- snip -- $ ksh93 -c 'printf "#PID=%d\n" $$ ; trap "echo l1_SIGUSR1 ; exit 0" USR1 ; (trap "echo l2_SIGUSR1 ; exit 0" USR1 ; exec kill -USR1 $$ & wait) ; print "#done."' #PID=1658 l2_SIGUSR1 #done. -- snip -- ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
