2014-12-14 20:48:45 +0000, Stephane Chazelas:
[...]
> $ bash -c 'declare a[1]="(1 2 3)"; declare -p a'
> declare -a a='([0]="1" [1]="2" [2]="3")'
>
> $ bash -c 'declare a+=([1]="1 2 3"); declare -p a'
> bash: line 0: declare: `a+': not a valid identifier
> declare -a a='([1]="1 2 3")'
>
> How do I do ATM if I want a[1] to contain "(1 2 3)" with
> declare?
[...]
I'm just realising the issue is nowhere as bad as I initially
thought it was.
x='($(uname>&2))' bash -c 'a[0]=x; declare a=$x'
is indeed a problem, but:
x='($(uname>&2))' bash -c 'f() { a[0]=x; declare a=$x; }; f'
is not, because when in a function, declare ignores variables by
the same name that have not been declared in that same scope
(even if they have been *set* in that context)
So it's more unlikely to be a problem than I thought it would be
as "declare" is mostly used in functions.
x='($(uname>&2))' bash -c 'f() { declare a[0]=x; declare a=$x; }; f'
would be a problem, but then why would one do that?
There's still a (security) issue with
declare -x/-l/-r
that may still be used in non-function contexts (not "export" or
"readonly"), and as result for things like:
saved=$(export -p var)
...
eval "$saved"
And with declare -g in functions, so probably still worth
addressing.
(the possible source of confusion issue, and compatibility
with ksh93 to consider as well)
--
Stephane
