Re: rc and signal handlers

Re: rc and signal handlers

[Byron Rakitzis]

signal handlers ARE function definitions. They just have the
added feature that they get run at "interrupt level". If
it's not obvious that you can't "return" from a signal
handler, then you need to think a little more carefully
about what signals are.

btw,

; fn sigint { echo hi }
; sigint
hi
;

Re: rc and signal handlers

[malte]

	
	| 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

Re: rc and signal handlers

[Chris Siebenmann]

| 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

rc and signal handlers

[malte]

I just came across a situation were I want to temporarily change the
sematics of a signal handler, say during the execution of a function.

	fn doit {
		sighdlr = `` $nl { whatis -s | fgrep 'fn sigint' }
		...
		eval $sighdlr
	}

doesn't work, of course. What is needed is a kind of local signal handler,
or a way to put a signal handler definition into a variable like

	fn doit {
		whatis fn sigint var
		...
		eval $var
	}

I suggest local signal handlers and local functions.

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. Signal handler
definitions look like functions but are *not*; it should be stated that one
cannot "return" from a signal handler.

Malte