On Saturday, September 26th, 2026 at 3:48 PM, Zachary Santer <[email protected]>
wrote:
> This doesn't work either:
>
> $ dash_A='-A'
> $ declare ${dash_A} assoc=( [zero]=0 [one]=1 [two]=2 )
> bash: declare: assoc: cannot convert indexed to associative array
> $ declare -p assoc
> declare -a assoc=([0]="2")
It does for indexed arrays and single values, quoted or not.
$ f() { o='-ia'; declare $o foo=(1 2 3); declare -p foo; }; f
declare -ai foo=([0]="1" [1]="2" [2]="3")
$ f() { o='-ia'; declare "$o" bar=(1 2 3); declare -p bar; }; f
declare -ai bar=([0]="1" [1]="2" [2]="3")
Until you add -g, then -i is lost and it behaves like the overquoted case.
$ f() { o='-gia'; declare $o baz=(1 2 3); declare -p baz; }; f; declare -p baz
declare -a baz=([0]="1" [1]="2" [2]="3")
declare -ai baz
There's no difference in effect whether $o, "$o", or "-gia" is used, all three
produce what appears to be *two* variables, one with correct attributes but no
value, and a local with type information lost.
Which might explain why the initializing expression for an -A is treated as if
-a was used. Bash is clearly parsing the -A, as it complains about conversion,
but then ignores it when parsing the array expression, perhaps it's looking at
the wrong variable?
If that's the case, then it working for -a at global scope may be by accident.
> What it's trying to do is perform arithmetic evaluation on "zero".
I've used bash for years and I'm ashamed to admit I didn't know about variable
names being used this way when -i is involved until yesterday *after* I posted.
Luckily I don't usually mix -i and non- -i, but more bugs for me to fix, fun. :)
> That first expression above gave us
> declare -a assoc=([0]="2")
> because "zero". "one", and "two" were all unset and thus evaluated to
> 0. But this is all fine.
If -a had been given to 'declare' like bash assumes, yes.
