> Next, it tries to gin up a shell variable for the expansion to apply to,
> to accommodate things like `-i', where the assignment will include things
> like arithmetic expansion. This is where it's important to detect `-g',
> since that determines the context where the variable is created. This is
> the evaluation order the `declare' builtin uses as well.

In that case, is my conjecture that it's creating two variables from one
command correct? One local because it doesn't detect the -g in time, with
a possibly misprocessed value because it doesn't detect an -A in time, and
then a global with no value because it has no value left to give it by the
time it actually detects the -g but tries to satisfy it either way?

> declare -Ag assoc; assoc=(one two three four)
> 
> which is how you should be writing these things in the first place.

So if -r or other attributes are involved as well, are users supposed to
always turn one command into at least three? Because there are gotchas
there too, like having to repeat -g otherwise -r applies to a new blank
local (which doesn't make any sense) instead of the existing global.

  $ f() { \
  > declare -gia a \
  > a=(1 2 3) \
  > declare -r a \
;declare -p a;};f;declare -p a


Reply via email to