rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: John (I've got some bad news for you, sunshine) Mackin <john@vetsci.su.oz.au>
To: The rc Get-Someone-Else-To-Do-The-Work List <rc@archone.tamu.edu>
Subject: Re: builtin exit
Date: Sun, 29 Dec 1991 06:45:53 -0600	[thread overview]
Message-ID: <199112292345.23238.rc.babum@vetsci.su.oz.au> (raw)
In-Reply-To: <694002955.8576.0@mycroft.bh.andrew.cmu.edu>

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.


      reply	other threads:[~1991-12-29 13:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1991-12-29 10:53 Julian L. Ho
1991-12-29 12:45 ` John Mackin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199112292345.23238.rc.babum@vetsci.su.oz.au \
    --to=john@vetsci.su.oz.au \
    --cc=rc@archone.tamu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).