[Top][All Lists]

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

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

From: Chet Ramey
Subject: Re: declare a="$b" if $a previously set as array
Date: Sun, 14 Dec 2014 15:34:00 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 12/8/14 9:51 PM, konsolebox wrote:
> On Sun, Dec 7, 2014 at 7:24 AM, Stephane Chazelas
> <address@hidden> 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    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

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