[NCLUG] Perl/bash SIGINT question

[Bob Proulx]

Marcio Luis Teixeira wrote:
> I came across this very informative page on the topic. Good reading
> for you programmers out there:
>
>   http://www.cons.org/cracauer/sigint.html
>
> While it didn't solve my problem, it did give me a fairly complete
> description of what shells really do with signals. And it points out
> I had been handling SIGINT incorrectly in my C++ programs
> anyway. Opps.

I finally pushed myself to read through this reference in some detail.
The author is absolutely correct in the closing sections about the way
to handle SIGINT in programs.  This is a very often misunderstood
process and it seems very few people actually do understand it these
days.  Even beloved and widely used programs such as rsync get it
wrong.  (Instead of properly handling this signal it exits with an
exit code 20!)  But fortunately most traditional Unix programs do get
it right.  (Sort for example needs to trap SIGINT in order to clean up
spill files in /tmp.  Sort is an example that does it correctly.)  I
argued this point in Ruby a few years ago and it still isn't correct
there.

The author also touched on a pet peeve with people who write shell
scripts but do not check the return code.  (The section talking about
a shell for-loop that doesn't exit on interrupt.)  Argh!  Not checking
the return code has been a bane forever and continues.  It has been a
motivation for exception handling but I think EH is harder to get
right and not easier.  Using 'sh -e' has its own set of issues.  Most
problems wouldn't be a problem if programmers would simply check for
errors and handle them instead of ignoring them.  Unfortunately no
space is given to how to write shell for-loops correctly.  (Answer:
Check for errors and handle them!)  Why are errors ignored?  Because
error checking tends to be tedious and space consuming and therefore
no one wants to spend the space on it.

However I felt that the author didn't open the case very well and
fixated upon emacs in the opening sections.  I am an emacs user and
advocate and just the same I felt that using implementation details of
emacs didn't help the article.  Most screen applications operate more
generically with the tty driver in raw mode.  In fact reading the
opening sections led me to think that the author may have been
confused about how a stack of programs actually operate!  I believe it
added more confusion than it removed.

My advice for anyone who reads that reference is to skip all of the
opening and start in only at "How to be a proper program".

Bob