Re: Error handling question

[Chris F.A. Johnson]

On Mon, 9 Nov 2009, Marc Herbert wrote:

> Greg Wooledge a ?crit :
>  
> > The problem being "how to use set -e in a consistent manner across all
> > shells"?  You can't.  set -e is unpredictable, unreliable, and should be
> > shunned.  As you can see by the last dozen or so message on this mailing
> > list, not even bash gurus (other than Chet) can figure out its semantics.
> > 
> 
> The fact that "set -e" is not the default looks like a big design
> mistake to me.

    Making it the default would be a huge mistake.

> I cannot understand how ignoring errors in a program and
> going on like nothing happened is a desirable thing.

    It isn't desirable. However, commands will sometimes fail; they
    are intended to fail. Their failure provides necessary information
    to the script.

    For example, if you want to know whether user 'john' is in the
    password file:

grep -q ^john: /etc/passwd

    Why would you want the script to exit if that fails? You want to
    get the return code and execute code depending on the result
    (which can be 0, 1 or >1; 'if grep ...' is not adequate).

> When I write a succession of commands in a script, a later command
> depends on the success of earlier commands more often than not and
> there is no point going on with the rest of script.

    Then you are not taking advantage of the power of the shell. Using
    a return code provides more than a two-way branch.

> Ignoring errors should be the exception and not the rule.

    Not using set -e does not imply ignoring errors; one *uses*
    errors.

> The same can probably be said for C.
> 
> 
> > Check for errors yourself on the commands that matter.  That way you'll
> > know what will cause termination and what won't.  Yes, I know, it means
> > your script is longer.  But longer is better than unpredictable.
> 
> ALL my commands matter so I practically cannot check the return status
> of everyone of them.  Instead I use "set -e" systematically. It
> works. It is unpredictable but I do not to care: a safety net with a few
> holes is way better than none at all. The very few times I actually want
> to ignore an error I just append " || true" to the corresponding
> command.

-- 
   Chris F.A. Johnson, webmaster         <http://woodbine-gerrard.com>
   ===================================================================
   Author:
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)