Hi,
In my projects, I'm using bash to manage large scale jobs. Works very well,
especially, when access to servers is limited to ssh. One annoying issue is
the error handling - the limits/shortcomings of the 'errexit', which has
been documented and discussed to the Nth degree in multiple forums.
Needless to say, trying to extend bash to support try/catch clauses, (like
other scripting solutions: Python, Groovy, Perl, ...), will be a major
effort, which may never happen. Instead, I've tried to look into a minimal
solution that will address the most common pitfall of errexit, where many
sequences (e.g., series of commands in a function) will not properly
"break" with 'errexit'. For example:
function foo {
cat /missing/file # e.g.: cat non-existing file.
action2 # Executed even if action 1 fail.
action3
}
set -oerrexit # want to catch errors in 'foo'
if ! foo ; then
# Error handling for foo failure
fi
I was able to change Bash source and build a version that supports the new
option 'errfail' (following the 'pipefail' naming), which will do the
"right" thing in many cases - including the above - 'foo' will return 1,
and will NOT proceed to action2. The implementation changes the processing
of command-list ( '{ action1 ; action2 ; ... }') to break of the list, if
any command returns a non-zero code, that is
set -oerrfail
{ echo BEFORE ; false ; echo AFTER ; }
Will print 'BEFORE', and return 1 (false), when executed under 'errfail'
I'm looking for feedback on this implementation. Will be happy to share the
code, if there is a chance that this will be accepted into the bash core
code - I believe it will make it easier to strengthen many production
systems that use Bash.
To emphasize, this is a minimal proposal, with no intention of expanding it
into full support for exceptions handling, finally blocks, or any of the
other features implemented in other (scripting) languages.
Looking for any feedback.
Yair
