[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-bash] Awkward behavior of empty arrays
From: |
Andy Chu |
Subject: |
Re: [Help-bash] Awkward behavior of empty arrays |
Date: |
Thu, 7 Sep 2017 09:23:05 -0700 |
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
- Re: [Help-bash] Awkward behavior of empty arrays, (continued)
Re: [Help-bash] Awkward behavior of empty arrays, Cristian Zoicas, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, Cristian Zoicas, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, Cristian Zoicas, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, Greg Wooledge, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays,
Andy Chu <=
Re: [Help-bash] Awkward behavior of empty arrays, Chris F.A. Johnson, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, DJ Mills, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, Chet Ramey, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, Andy Chu, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, Chet Ramey, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, Andy Chu, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, Chet Ramey, 2017/09/09
Re: [Help-bash] Awkward behavior of empty arrays, Chet Ramey, 2017/09/07
Re: [Help-bash] Awkward behavior of empty arrays, Andy Chu, 2017/09/06