> e doesn’t work for (subshell | commands)

That's not an argument against enabling it.

In bash, -o pipefail addresses this.

> and u is inconvenient when appending to PATHs

PATH should always be set. Try: env -i sh -c 'echo $PATH'

If you're prioritizing convenience over correctness, prepare to face the consequences.

> Every tool has its place, and dogma is often unhelpful.

Visual Basic's "ON ERROR RESUME NEXT" perhaps also had its place. That doesn't mean that using it is good advice.

If anything, I would consider the often cited wooledge etc. advice of not using -e/-u as dogma. Case in point: no one lost 77TB of data because they should not have used -e/-u.

I said PATHs, not PATH. There are at least four I use on a regular basis.

Super not interested in a pedantic debate. It’s easy to armchair analyze. I found flaws in 55 codebases at Matasao, and yours is no exception.

e makes it super annoying to pass a variable number of args to a script, since shift will fail and cause an exit.

I do usually turn it on after, but you seem like the type to fail a code review if a script doesn’t start with it. I don’t think that’s a productive attitude.

I disagree. You can write shell scripts just fine and always set -euo pipefail

* I'm not sure what you mean by four PATHs, but if you really mean to be using unset variables for them, you should be using " ${V-}" or "${V:-}" syntax which does not fail. But again I don't know why you would do this other than maybe [[ "${1-}" ]]

* Variable arguments are still trivial with $#. Check (($#>3)), use while (($#>0)), etc

I also disagree that this is unproductive. With minor modifications/(adding :- or -), you can prevent a whole class of bugs (undefined variables). This woukd have prevent real-world issues such as in the post here as well as Steam when it wiped home directories since it ran (not sure the exact syntax) rm -rf $STEAMROOT/* with an unset variable

That's quite a number of bad-faith assumptions in your comment, which are also incidentally wrong.

> e makes it super annoying

I rest my case?

I don't think the audience is interested in this. If you'd like to be specific, I'm happy to talk about specific critiques. Otherwise it's just posturing, and there are better things to do over the holidays.

The original assertion was that under no circumstances should a bash script not begin with -e. I gave a circumstance (passing optional arguments), and said dogma is often counterproductive. I stand by all of those.

Let's agree to disagree and move on.

I kind of agree with your point that there should be exceptions, but I think I also agree with OP that using -e as a general rule is probably a safe starting point.