FWIW, I can assure you I did not deliberately walk into minefields while developing my recent bash project, and yet I've struggled with `errexit` and `errtrace` to the point where I've ceased to use them, preferring to just ` || die` everything which may possibly fail. Although you may say that simply choosing to use bash is self-defeating already...

Have you reviewed the examples on this page, linked from the FAQ?

http://fvue.nl/wiki/Bash:_Error_handling

Respectfully, this is nuts. You consider it a problem with 'set -e' that, if someone runs your script via

  % bash foo.sh

then a '-e' on the shebang line of foo.sh will be ignored. That's a more general issue, separate from -e. You can say users who do that deserve what they get (not unreasonable IMHO), or you can use a 'set -e' within the script. But don't say it's a problem with -e. It's actually a problem with running command interpreters on arbitrary files.

I can't read any more of these examples. I think you need more experience with shell, or maybe we have incommensurate approaches/expectations.

I'm not of the view that using bash/sh in itself is a bad choice. There are lots of problems that it's well-suited for, and I myself use sh scripts a lot (with a linear flow that can go on for hundreds of lines). In particular, I don't think python is a good replacement for my use cases.

What are you talking about? Are you reading the same page as me?

Let me quote http://fvue.nl/wiki/Bash:_Error_handling Caveat 1:

    #!/bin/bash -e
    echo begin
    (false)
    echo end

Executing the script above gives:

    $ ./caveat1.sh
    begin
    end
    $

This has nothing to do with "ignoring the '-e' on the shebang line."

This is bash ignoring the exit status of the explicit subshell, even though `errexit` is set.

Sorry, my impatience led me to misread the page.