* signal weirdness @ 1996-11-13 14:06 Zefram 1996-11-13 17:41 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Zefram @ 1996-11-13 14:06 UTC (permalink / raw) To: Z Shell workers mailing list I got these results on Solaris 2.5.1 and SunOS 4.1.4, not tested anywhere else. Create a program called "segv", from this source or something equivalent: main() { *(volatile char *)0 = 1; } (I.e., the program will die with a SIGSEGV.) Run the script: trap 'echo SIGSEGV' SEGV foo=$(segv) echo finished exit 0 When the segv program terminates, zsh acts as if it had received a SIGSEGV (it executes the trap), despite the fact that it was its child process that received it. This doesn't happen if the signal is not trapped. The same happens if the command is run directly, rather than being within $(). I'm not looking into this at the moment; I'm not familiar with the signal code, and I have more urgent things to do. I hope someone can diagnose this. -zefram ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: signal weirdness 1996-11-13 14:06 signal weirdness Zefram @ 1996-11-13 17:41 ` Bart Schaefer 1996-11-13 18:03 ` Zefram 0 siblings, 1 reply; 4+ messages in thread From: Bart Schaefer @ 1996-11-13 17:41 UTC (permalink / raw) To: Zefram, Z Shell workers mailing list On Nov 13, 2:06pm, Zefram wrote: } Subject: signal weirdness } } When the segv program terminates, zsh acts as if it had received a } SIGSEGV (it executes the trap), despite the fact that it was its child } process that received it. This doesn't happen if the signal is not } trapped. } } I'm not looking into this at the moment; I'm not familiar with the } signal code, and I have more urgent things to do. I hope someone can } diagnose this. Around line 180 in jobs.c: /* WHY DO WE USE THE RETURN STATUS OF PROCESS GROUP LEADER HERE? */ /* If the foreground job got a signal, pretend we got it, too. */ if (inforeground && WIFSIGNALED(status)) { if (sigtrapped[WTERMSIG(status)]) { /* Run the trap with the error flag unset. * Errflag is set in printjobs if the jobs terminated * with SIGINT. I don't know why it's done there and * not here. (PWS 1995/06/08) */ errflag = 0; dotrap(WTERMSIG(status)); /* We keep the errflag as set or not by dotrap. * This is to fulfil the promise to carry on * with the jobs if trap returns zero. * Setting breaks = loops ensures a consistent return * status if inside a loop. Maybe the code in loops * should be changed. */ if (errflag) breaks = loops; } else if (WTERMSIG(status) == SIGINT || WTERMSIG(status) == SIGQUIT) { breaks = loops; errflag = 1; } This code is intended to handle (among other things) the case where the user types the interrupt character when a foreground job is executing, thereby causing zsh to behave the same as if interrupt were typed at a bare prompt. Similarly, if the user typed the quit character, or if the foreground job got a HUP because the tty line dropped, we want zsh to notice and behave as if it got the signal as well. But (except for INT and QUIT), the signals are only interesting if they're trapped, as zsh normally ignores the rest. I don't know who wrote the "WHY DO WE ..." question, and I'm not sure exactly what's being asked. Why is it the group leader's status? Or why is it the status at all? It's the group leader because the group leader gets the tty-generated signals, and it's the status because the type of signal received by the job can be extracted from the status. Anyway, the code is more general than it needs to be -- there is only a subset of signals (HUP, INT, QUIT, TSTP, ...) that really need to be handled this way. On the other hand, there's no way to make a good comprehensive cross-platform list of all the signals that should be so treated, which is why it's as general as it is. It might be possible to come up with a list of signals that we know should *not* be treated this way (BUS, FPE, SEGV, others?) and explicitly omit them, if this is really annoying for some reason. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: signal weirdness 1996-11-13 17:41 ` Bart Schaefer @ 1996-11-13 18:03 ` Zefram 1996-11-13 18:32 ` Bart Schaefer 0 siblings, 1 reply; 4+ messages in thread From: Zefram @ 1996-11-13 18:03 UTC (permalink / raw) To: schaefer; +Cc: zefram, zsh-workers > /* If the foreground job got a signal, pretend we got it, too. */ Oh. >This code is intended to handle (among other things) the case where the >user types the interrupt character when a foreground job is executing, >thereby causing zsh to behave the same as if interrupt were typed at a >bare prompt. Similarly, if the user typed the quit character, or if >the foreground job got a HUP because the tty line dropped, we want zsh >to notice and behave as if it got the signal as well. But (except for >INT and QUIT), the signals are only interesting if they're trapped, as >zsh normally ignores the rest. I don't see the problem with just ignoring the situation, in the case of key-generated interrupts. If the user wants to kill a program *and* have the shell process a SIGINT handler, e can press ^C twice. HUP is the only one that we really need to handle specially. >Anyway, the code is more general than it needs to be -- there is only >a subset of signals (HUP, INT, QUIT, TSTP, ...) that really need to be >handled this way. On the other hand, there's no way to make a good >comprehensive cross-platform list of all the signals that should be so >treated, which is why it's as general as it is. Shouldn't it be only INT, QUIT and HUP? I can't see any others that could justifiably be treated this way. > It might be possible >to come up with a list of signals that we know should *not* be treated >this way (BUS, FPE, SEGV, others?) and explicitly omit them, if this >is really annoying for some reason. It is very annoying. It seems like the shell is going out of its way to cause inconvenience: without that code it would be easy to distinguish between an external program crashing and the shell crashing. What does POSIX say about all of this? -zefram ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: signal weirdness 1996-11-13 18:03 ` Zefram @ 1996-11-13 18:32 ` Bart Schaefer 0 siblings, 0 replies; 4+ messages in thread From: Bart Schaefer @ 1996-11-13 18:32 UTC (permalink / raw) To: Zefram; +Cc: zsh-workers On Nov 13, 6:03pm, Zefram wrote: } Subject: Re: signal weirdness } } I don't see the problem with just ignoring the situation, in the case } of key-generated interrupts. If the user wants to kill a program *and* } have the shell process a SIGINT handler, he can press ^C twice. HUP is } the only one that we really need to handle specially. Csh, at least, invokes its onintr handlers when any process spawned from a csh script gets a keyboard interrupt. /bin/sh (pre-POSIX, at least) invokes its INT traps on a single interrupt, AFAIK. Sometimes the shell is in a loop spawning jobs too fast for pressing ctrl-C twice to have the desired effect. What good is an INT handler if zsh never gets the signal? } What does POSIX say about all of this? I'd be interested, too. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1996-11-13 21:06 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-11-13 14:06 signal weirdness Zefram 1996-11-13 17:41 ` Bart Schaefer 1996-11-13 18:03 ` Zefram 1996-11-13 18:32 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).