bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error handling question


From: Greg Wooledge
Subject: Re: Error handling question
Date: Mon, 9 Nov 2009 09:10:02 -0500
User-agent: Mutt/1.4.2.3i

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]