On Wed, Nov 28, 2007 at 12:23:36AM -0500, Glenn Fowler wrote:
>
> On 20 Nov 2007 15:43:02 -0800 Icarus Sparry wrote:
> > You might find this web page interesting; it discusses what various
> > shells do when given sigint.
> > http://www.cons.org/cracauer/sigint.html
>
> thanks
>
> the fix we have in place works like the WCE case in that url
> but the regression test for the fix shows that WCE has sub-cases
> that further differentiate shell implementations
>
> one of the differences is an inconsistency that ksh93 will not replicate:
> if a parent traps SIGINT and the child process catches SIGINT and exits
> normally then the parent SIGINT trap is not called
> (some shell implementations call the parent SIGINT trap in this case)
> why is that inconsistent?
> if the parent does not have a SIGINT trap then those same shell
> implementation do not take the default SIGINT action and instead ignore SIGINT
If I'm reading the test results correctly, and according to my own tests, *all*
of the other shells behave this way. Calling an explicitly set trap regardless
of how the running child exited is the behavior that I want in all of the cases
for which ksh93's IUE was a problem for me. As the "Proper handling of
SIGINT/SIGQUIT" page notes, there are programs that trap and exit with 0
status, and so do not communicate killed-by-signal properly. The shell program
trap handler should have the opportunity to deal with this, which it can do
only if it's called. It may also be desirable to provide a way of ending a
shell program that is executing a series of programs, each of which ignores
keyboard signals.
Perhaps the exit status could be made available in the trap handler in e.g. $?
so that the handler could make its own decision about whether to exit? My wish
would be for the default behavior of ksh93 to match that of all of the other
shells, but any way of getting that behavior (an option to trap?) would be
sufficient.
John
--
John DuBois [EMAIL PROTECTED] KC6QKZ/AE
I wish to God these calculations had been executed by steam. - Charles Babbage
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
