Re: set subtract

Re: set subtract

[malte]

	
	 The problem with a set-subtract function is that it will loose quoting
	information if it's used as 'foo `{set-sub ....}', and you thus need to
	have it passed variable names to work on. But then you can't just use
	this on a command line; you have to build lists beforehand. About
	half the time I'd like to use this is on command lines, so I keep
	wishing for a better solution.
	
		- cks

Applause, applause!

I'd vote for making such a function built into rc to avoid meta character
trouble, the way the ~ operator does it.
A related builtin I always wanted to have:

	idx = `{ index list_of_patterns list_to_search_in }

This should return a list of indices of the search patterns in the second list.

	; echo `{ index a ( a b c a ) }
	1 4
	;

Malte

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

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
;

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