[NCLUG] I think

[Bob Proulx]

Alan Silverstein wrote:
> > ...it's worth the effort to include traps:
> 
> Right.  Over the years my own mental template evolved to include a
> standard set of signals in nearly all scripts I wrote, and later to
> using symbolic rather than numeric parameters.  Now what was that list
> again?  Danged retirement fuzzies...  Based on the bash(1) manual, it
> must have been at least these:
> 
>     trap ... HUP INT QUIT PIPE TERM 

Be careful trapping PIPE if the trap handler prints any output.
Otherwise you it will trigger another SIGPIPE and it will repeat
until hitting the stack size limit.

Basically you can treat HUP INT QUIT TERM all the same.  But if PIPE
needs to be trapped then it can't make any output.  That restriction
might make it different from the rest if the rest do make output.  For
SIGPIPE trap handling it is best to reset to the default as soon as
possible and then do any trap handling.  Reseting to the default will
mean that if any output is printed that it will trigger a SIGPIPE but
now that the trap handler is back to being the default again it will
simply exit appropriately since that is the default behavior.

Also note that if you are simply talking #!/bin/bash specifically and
not generic #!/bin/sh in general (/bin/sh is symlinked to dash on many
systems) then you can simply set a trap on EXIT only and cover
everything.  In bash, ksh, and zsh setting EXIT sets up a trap handler
upon shell exit for any reason including all of the other signals.  So
for bash et al EXIT is a simple one stop shop for trap handling.

But...  There should be a reason for installing a trap handler.
Because it is a little messy and few people understand them it is
better not to have them unless you need them.  It is simpler that way
and simpler is better.

Bob