Re: signal weirdness

[Zefram <zefram@dcs.warwick.ac.uk>]

>    /* 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