Two simple tricks for better shell script error handling
turnkeylinux.org
turnkeylinux.org
If you decide to trap INT or TERM, it would be wise to properly kill your process with INT or TERM:
# if you're using bash, you can use $BASHPID in place of $$
for sig in INT TERM EXIT; do
trap "rm -f \"\$TMPFILE\"; [[ $sig == EXIT ]] || kill -$sig $$" $sig
done
Not propagating signals in this manner is being a bad Unix citizen. Bash would have re-raised the SIGNAL, so you should too.For more information: http://www.cons.org/cracauer/sigint.html
(replied to on blog comments as well)
More or less sane systems have something like this (Ubuntu 9.10):
$ ls -l /bin/*sh
-rwxr-xr-x 1 root root 917960 2009-09-14 06:08 /bin/bash
-rwxr-xr-x 1 root root 101608 2009-09-21 00:49 /bin/dash
lrwxrwxrwx 1 root root 4 2009-10-29 19:25 /bin/rbash -> bash
lrwxrwxrwx 1 root root 4 2009-05-17 19:57 /bin/sh -> dashIf you're arguing that classic shell scripting doesn't carry you all that far, I would agree, but I don't see the harm in using #!/bin/bash or #!/bin/ksh in lieu of sh the few times you are writing a shell script; they are both extremely common and feature many conveniences.
Having ksh93 available on all systems was pretty nice, and there definitely was a place for some of the features without going for something else (which in this case mostly was Perl).
OTOH, I believe the error handling tricks discussed should work with any POSIX shell so I've updated the shebang line in the code snippets to use the more generic #!/bin/sh.
Something that can help pin down usage of bash extensions is checkbashisms (in the devscripts package on Debian systems). Also running the script through a shell that claims POSIX compliance like /bin/dash.
% ln -s /bin/bash sh
% ./sh
sh-3.2$ echo {1..10}
1 2 3 4 5 6 7 8 9 10
sh-3.2$ exit
% dash
$ echo {1..10}
{1..10}
where dash is supposed to be POSIX compliant.