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

[Chet Ramey]

On 12/8/14 9:51 PM, konsolebox wrote:
> On Sun, Dec 7, 2014 at 7:24 AM, Stephane Chazelas
> <stephane.chazelas@gmail.com> wrote:
>> $ b='($(uname>&2))' bash -c 'a=(); declare -r a=$b'
>> Linux
> 
> I actually also don't like that form of implementation.  Even if declare
> is a builtin and not a reserved word, it still has some special
> treatments that's different from a simple command.  For example in a
> simple command like echo, something like 'echo a=(1 2 3 4)' would cause
> syntax error.  Word splitting and pathname expansion also doesn't happen
> unless when assigning elements in an array.  If declare is able to
> recognize assignments separated by spaces, I think it would have not
> been difficult avoiding $b to be evaluated since it's really not meant
> to be.  It clearly is a simple form of assignment.  Imo even if declare
> is a builtin (which is actually a little special over a normal one), it
> should have just emulated behavior of normal assignments and did nothing
> more than it besides declaring the type (and optionally have some other
> features not related to assignment).

It does implement `emulated behavior of normal assignments'.  The question
is whether or not it should do that after having had its arguments undergo
one round of word expansion.

> (But I think those who used to recommend using declare as a general tool
> for assigning values remotely over evil eval would love it since
> it makes assignments like `declare -g "$var=$something"` possible
> which naturally should have been illegal.)

Why should this have been illegal?  Even Posix acknowledges that constructs
like `export $one=$two' are valid.  The question is what to do about
compound assignment.

> Anyhow, this problem would only happen if a variable in a specific
> scope (and only in that scope) has already been set previously as an
> array and it doesn't always happen if you write your scripts well.
> 
>> It may be worth recommending people do a "unset var" before
>> doing a "declare [-<option>] var"
> 
> I actually find it better to mention that on a simple assignment like
> declare var=$something, var's type doesn't change if it has already been
> declared previously as an array.

As I mentioned in a previous message, there's no reason for a script writer
to expect that `declare x=y' unsets x.  Assignment without using `declare'
doesn't.  Maybe it is worth saying that nothing will change an array
variable's type, though it's possible to promote a variable to an array.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/