builtin exit

builtin exit

[Julian L. Ho]

It would be nice if exit took strings like 'sigint', etc... just a
single string (a list like return handles wouldn't be possible, I
know).

It would also be nice if signal handlers had some way of telling how
they were called (I'm thinking setting $status on entry to signal
handlers, or possibly $*, to some meaningful string).

For example, I'd like something like this to work:

    pipes=()

    fn sigexit sigint sigquit { s=$status {
	rm $pipes
	exit $s
    } }

    #code that builds $pipes (list of files) and does things with
    #it

The idea is to have the script exit with 'sigint', 'sigquit', the
argument to builtin exit (if its used), or the exit status of the last
command (if we just fall off the end in "code...")...

Currently, I'm doing something like:

    pipes=()

    fn sigint sighup sigquit {
	rm $pipes
	exit 1
    }

    #code...

    # Normal exit follows (a copy of the cleanup code in the handler)
    rm $pipes

But that only works because my code doesn't call builtin exit in the
middle...  also, exiting with the exit status of the cleanup code (rm
in this example) isn't necessarily correct.  If the user causes an
interrupt, the cleanup actions are taken but the exit status is 1, not
'sigint', or whatever...

Re: builtin exit

[John Mackin]

No changes to rc are needed to do any of this.  As to getting the
exit status right, the way we've been doing it for years in sh is
still perfectly adequate; adapted for rc, it's like this:

estat = 0

fn sigexit {
	# place any cleanup actions here
	builtin exit $estat
}

fn exit {
	if ( ! ~ $#* 0 ) {
		estat = $1
	} else
		estat = 0
	builtin exit		# in order to get sigexit invoked
}

This works just fine for, on the one hand, making sure that
cleanup happens, and, on the other, making sure that if the
script says "exit <something>", then "something" is indeed
its exit status (which is, of course, the problem with
straightforward use of sigexit).

Most scripts don't need this trick, but it's an easy one when
it is needed.  It doesn't require bending the body of the script
in any way, except that if you are weird enough to want the
exit status to indeed be that of the last synchronously executed
command, rather than zero, if you `fall out the end', then you
need to add "exit $status" to the end of the script.  I can't
think of many applications where this is necessary or desirable.

And if you have truly been taking VERY strange substances, and
believe that it actually matters that the script exits with
a SIGINT even though the interrupt you sent it was handled
by the script, well you can do that too.  Do the above,
encapsulating the cleanup actions in a function called
"cleanup".  Then:

sigs = (int quit hup)	# the signals we're weird enough to want
			# to do this with

for (s in $sigs) {
	eval fn sig ^ $s '{'				\
		cleanup ';'				\
		fn sig ^ $s ';'				\
		kill - ^ ` { tr a-z A-Z <<< $s } $pid	\
	'}'
}

Caveats: (1) SysVile versions of tr will need square brackets;
(2) some systems still probably have versions of kill(1) that
insist on signal numbers instead of names, but that's just
a matter of detail.  I've tested this and it works, under rc 1.2;
things may well change with the release of 1.3, which will have
completely reworked signal handling.  Because of 1.2's special
handling of sigint (which, I might add, is 100% justified from
my point of view), the code above doesn't actually give sigint
back to the parent; it works fine for the other signals, though.

To conclude, I'd just like to state my main points again:
firstly, most scripts don't need the elaborate exit status
handling I presented initially.  For the occasional one that
does, it's easy.  Secondly, I don't think ANY script needs
the bizarre signal status handling that was proposed.
But, finally, if you do happen to need it -- it's _there
already_, thanks to the clean design of rc; no more `features'
are needed for any of this.  While the exit status handling
was just as easy in sh, the mere thought of trying to get the
quoting right to handle the signal status -- if it could be done
at all -- fills me with eldritch horror.

_Clean design pays ongoing dividends._

OK,
John.