Re: [Help-bash] Awkward behavior of empty arrays

[Andy Chu]

On Thu, Sep 7, 2017 at 5:44 AM, Greg Wooledge <address@hidden> wrote:

> On Thu, Sep 07, 2017 at 02:32:12PM +0200, Cristian Zoicas wrote:
> > Could you explain why -u is horrible? Does it have some drawback?
>
> http://mywiki.wooledge.org/BashFAQ/112
>
> At least it's not set -e.  set -e has no possible justification at
> all.  set -u is merely... quirky.
>

I agree that both are quirky, but even with quirks they're still useful,
and I use them exclusively.  "no possible justification" is hyperbole --
plenty of people use them.

I believe MOST serious shell users use set -e.  Look at debootstrap -- it's
a few thousands lines of shell at the foundation of Debian.  They could
have stopped using it any time in the last 20 years but didn't.  I also
looked at the bash scripts at the foundation of Nix -- same thing.


set -u:

- For environment variables, typically my scripts begin with

readonly SOMEVAR=${SOMEVAR:-}

This has the nice side effect of actually declaring what environment
variables your script uses!  Otherwise when you see $SOMEVAR you don't know
if it is an env var or a global in some other module you've sourced.

- I didn't know about the empty array thing, but apparently that's fixed in
bash 4.4 (and there is a known workaround in 4.3 and earlier,
${A+"address@hidden"} which I just found about).

set -e:

There are lots of nice examples here: http://mywiki.wooledge.org/BashFAQ/105

In practice I only run into one issue:

local foo=$(echo hi; false)

->

local foo
foo=$(echo hi; false)

(However local foo='bar' is fine because there's no possibility of failure.)

I never really use subshells; those need another set -e at the top.  There
is a new set -o inherit-errexit option but I haven't used it.

I never really used 'echo $(foo)', instead I assign it to a variable first.

I did a very principled implementation of errexit in OSH.  I didn't find
any problems with it in THEORY.  Yes in practice bash has surprising
behavior, but in theory it's a good idea, and it's not hard to implement.
There are just a handful of places where you turn it off: the condition of
while/until loops, if conditions, all clauses in && and || except the last
clause, etc.

The main thing I disallowed was the weird behavior mutating errexit while
it's disabled, which bash has a somewhat odd rule for.  Example:

if { true; set -o errexit; false; }; then
  echo hi
fi

FWIW I tried to switch to explicit error handling once, but that just
ruined the entire reason I use bash: because it gets things done fast.  If
I want to do explicit detailed error checking I'll use another language.
As I said, MOST serious scripts I see use set -e.

Andy