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'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
> e makes it super annoying
I rest my case?
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.