On Mon, Nov 09, 2009 at 03:49:09PM +0200, Ciprian Dorin, Craciun wrote: > Unfortunately I'm not subscribed to this mailing list. Could you > point me to the right thread?
http://lists.gnu.org/archive/html/bug-bash/2009-11/threads.html And... pretty much every month, especially since bash 4 changed the behavior of set -e. > P.S.: The fact that some features of Bash, mainly `set -e`, which > should be a safety-net for scripts, is "unpredictable" is not so very > reassuring... More-over the entire Linux / Unix software > infrastructure is based on Bash, from init scripts, to complex > applications [...] (Actually, you might be shocked to see that many newer Linux distributions use dash, not bash, for their init scripts.) What you say might be true for some versions of Linux, but the entire _Unix_ shell infrastructure is based on the the Bourne shell, and the practice of using the absolute lowest common denominator feature set in order to make your script run everywhere. With Solaris still shipping a Bourne shell (rather than a POSIX shell) in /bin/sh that means you're stuck with 7th Edition semantics unless you're willing to put in tricks to try to re-invoke your script under /usr/xpg4/bin/sh or /bin/sh5 or ksh or bash or whatever. When you have to worry about whether you can use functions or $() or [[:alpha:]] or arithmetic or other POSIX features in your scripts, set -e is just another thing you *don't* want to have to mess with. It's so much easier to check for errors yourself than to have to worry about whether your complex nested conditional loop switch structure thing will break set -e on Dynix or SCO.
