bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: declare a="$b" if $a previously set as array


From: Stephane Chazelas
Subject: Re: declare a="$b" if $a previously set as array
Date: Sun, 14 Dec 2014 21:44:16 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]