From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from techfac.techfak.uni-bielefeld.de ([129.70.132.100]) by hawkwind.utcs.toronto.edu with SMTP id <2776>; Fri, 6 Nov 1992 07:03:55 -0500 Received: from dahlie.TechFak.Uni-Bielefeld.DE by techfac.techfak.uni-bielefeld.de (5.65+bind 1.7+ida 1.4.2/tp.270592) id AA04434; Fri, 6 Nov 92 13:03:36 +0100 Received: by dahlie.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA01626; Fri, 6 Nov 92 13:03:35 +0100 Date: Fri, 6 Nov 1992 07:03:35 -0500 From: malte@techfak.uni-bielefeld.de Message-Id: <9211061203.AA01626@dahlie.techfak.uni-bielefeld.de> To: rc@hawkwind.utcs.toronto.edu Subject: Re: rc and signal handlers In-Reply-To: Mail from 'Chris Siebenmann ' dated: Thu, 5 Nov 1992 18:16:05 -0500 | Also, the man-page is not too clear about signals: | "Only signals that are being ignored are passed on to programs run by rc" | The should read "signals that are being caught", I guess. The manpage is correct as written; caught signals are not passed on to children, and revert to default behavior. Only ignored signals are passed on to children. If one thinks about how catching signals works, it becomes obvious that this has to be that way. - cks This is perfectly true! But also ugly ! This way, one has to redefine signal handlers for each backquote substitution. On BSD and System V children inherit signal handlers when forking and one has to change them explicitly. Could someone explain to me why rc does it automatically ? I'd rather prefer a simple way to reset signal handlers, something like fn sigreset { for( sig in `{ whatis -s | cut -f2 '-d ' } ) eval fn $sig } About "return"ing from a signal handler: One really doesn't want to do that. I just mentioned it to make it clear to beginners. What bothers me most is that rc doesn't complain about a return when defining the function and that everything is fine when invoking the function interactively. But, when the signal is caught, you'll get "return outside of function". Malte