Peter Eisentraut points out that in Bash you can run “set -o pipefail” to handle some failure cases for pipelined commands.

use shell scripting quite a lot, because in my spare time I play around a lot with software that is already 90% shell scripts which manage a few binaries, and there’s no guarantee that the boxes have anything else available (though Perl is usually there and has sometimes been used by others). The software is also designed to run unattended for months on end, so the scripts have to be able to deal with common situations without intervention, and if they fail, fail gracefully.

However, for quick and dirty scripts, the techniques outlined in the blog post are a good way to avoid too many tears.

Also, I understand why people might argue that if you write anything in shell script that would be worth the effort to do it ‘right’, you might as well do it in a ‘proper language’ such as Python or Ruby for example.

I wrote some bigger stuff in bash, but that’s because I’m just crazy. There is no other reason for it.

Putting “set -e” at the start of a script is easy, simple, and solves many problems. While it’s not ideal, it will save servers from being trashed on occasion and that’s what really matters.

But your points are good and are useful for anyone who wants to take their scripting to a higher level.

I think the set -e option is just an excuse for not writing proper error handling routines and fail safe code. The || exit 1 statements seem like an ugly solution to me.

#!/bin/sh
cd /tmp/whatever || exit 1
rm -rf *

Could be better written something like:

#!/bin/sh
DIR=/tmp/whatever
if [ -e "$DIR" ] && [ ! -z "$DIR" ]
then
rm -rf “$DIR/*”
fi

If you want to run dangerous commands like ‘rm’ you may want to spend the 2 minutes extra to write a ‘proper’ fail safe mechanism instead of using set -e or other simple solutions.

But that is just me.