e doesn’t work for (subshell | commands), and u is inconvenient when appending to PATHs. Every tool has its place, and dogma is often unhelpful.

> 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.

I long adopted

    /bin/sh -eu

header in my scripts. It's a must-have.

If you mean as a shebang (#!/bin/sh -eu), I would suggest switching to using "set" instead, because the shebang will not be interpreted if the script is ran as "sh script.sh" (as opposed to ./script.sh).

Perdon my ignorance, but what do those do? Searching for it doesn't give me anything.

See https://www.gnu.org/software/bash/manual/bash.html#The-Set-B..., in short -e makes scripts exit if a command fails, and -u makes them exit if a variable is undefined.

If you think your colleagues won't know this, "set -o errexit; set -o nounset" would be easier for them to search on.

(Via "3.4 Shell Parameters" → "3.4.1 Positional Parameters" → "4 Shell Builtin Commands", or searching the whole page for "-e".)

Thank you very much, I appreciate it.