passing ignored signals into subshells

passing ignored signals into subshells

[Chris Siebenmann]

 It would be nice if rc had some way of doing this, like sh's "trap ''
SIGNUM". The obvious thing would seem to be special-case 'fn sigSIG
{}', but that might not be very easy or clean interally. Thoughts,
anyone?

	- cks

Re: passing ignored signals into subshells

[John Mackin]

Chris writes:

     It would be nice if rc had some way of doing this, like sh's "trap ''
    SIGNUM". The obvious thing would seem to be special-case 'fn sigSIG
    {}', but that might not be very easy or clean interally. Thoughts,
    anyone?

Well, my first thought is that I would be very interested to know
what version/s of sh do this.  I've just tried a Pike-based sh and
the standard SunOS sh, and neither one does it; if you set traps
for ignored signals, then run a subshell and type "trap", it has not
inherited the ignores.

That said, I'm prepared to say that on initial exposure and without
having considered the matter at any great length, this sounds like a
good idea to me.  The important point, it seems to me, is that if you
set a trap for an ignored signal in a given shell, what you really
want is for all children spawned by that shell to be ignoring the
signal also, and not just for the shell process to be ignoring
the signal.  This, it seems to me, is the crucial design question,
and I'd be interested to hear what others on the list think about it.

If one accepts that the design point is good, then the implementation
seems pretty clear to me.  There is no point special-casing the
signal functions, since that would only make the ignoring effective
in rc's spawned by the rc where the trap was set, and not in every
process spawned by it.  The implementation has to be that if a signal
has an ignore function in an rc, then the signal should remain ignored
in processes spawned by the rc.  This does not occur in rc1.1gamma;
sorry I'm a bit behind the rc times here.  If this has changed since,
perhaps someone could let us know.  You can test it like this:

; fn sigiot {}
; sleep 200 &
; kill -6 $apid
; ps
<-- see whether the sleep is still running -->

In 1.1gamma, on my system, the process has been killed.  So, rc is taking
special care to reset ignored signals to the default value in child
processes, since the standard UNIX semantics are that ignored signals
remain ignored across fork and exec.  If we accept the design
point (i.e. that this special resetting shouldn't be done), then the
implementation falls out, in two stages: (1) remove the code that is
doing the above-mentioned special care; (2) when an rc starts, run
through all the signals (maybe with some exceptions, like SIGCLD on
a NOSIGCLD machine) checking for ones that are ignored, and on
finding any ignored ones, install a "fn sigXXX {}" handler for
them.  That way, any sub-process of an rc that is ignoring signals
does the right thing, regardless of whether it is an rc or some other
process.

Further comments?

OK,
John.

Re: passing ignored signals into subshells

[Chris Siebenmann]

 sh seems to do funny things to inherited signals, but if you check
with a program that checks signal statuses, you'll see that programs
do inherit ignored signal(s) (at least on Ultrix, SunOS 4.1, and
4.3Tahoe/Reno).

 Currently, rc doesn't seem to ever set signals other than SIG_QUIT to
SIG_IGN; 'fn sigNAME {}' catches the signal, but runs '{}', which
doesn't actually do anything. Logic would have to be added to recognize
a 'null' signal catching function and use SIG_IGN instead.

	- cks