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

[Chet Ramey]

On 12/16/14 4:49 PM, Stephane Chazelas wrote:

> I believe my proposal in Message-ID:
> <20141214204845.GA5345@chaz.gmail.com>
> http://thread.gmane.org/gmane.comp.shells.bash.bugs/22737/focus=22789
> 
> would be the most consistent syntax. But that breaks
> compatibility especially as it means the output of declare -p on
> arrays would no longer work.
> 
> Now, like Dan, I think we can have a middle ground that doesn't
> break backward compatibility as much but would remove most of
> the security concerns.

Thanks for this.  There are really only a couple of changes to the
current behavior.


> 1.2 litteral scalar assignment
> 
> x="a b" y='($(uname))'
> declare $options a=$x b=~ c='(1 2)' d='($a)' e=$y
> 
> those are *parsed* as scalar assignments in that ~ is expanded
> and $x doesn't undergo split+glob, but after that parsing and
> expansion is done, depending on whether -a/-A was passed or not,
> those "a=a b" "b=/home/stephane" "c=(1 2)" "d=($a)"
> "e=($(uname))" arguments are interpreted differently.
> 
> If -a is passed, that becomes:
> 
> a=([0]="a b")
> b=([0]="/home/stephane")
> c=([0]=1 [1]=2)
> d=([0]=a [1]=b)
> e=([0]=Linux) # second round of evaluation but if you didn't
>             # want that you could still do e=("$y")

This stays for backwards compatibility.  I have some code in there
(commented out) that changes it based on the shell's compatibility
level setting.

> declare $options a[1]='(1 2)'
> 
> however sets a[1] to '(1 2)' regardless of whether -a, -A or
> neither is passed.

This is one of the changes.  In previous versions, the [1] was treated as
a subscript sizing the array and accepted for backwards compatibility (but
always ignored).  In the current development code, the assignment is
performed on a[1] if the variable previously existed as an array, and
behaves as in bash-4.3 otherwise.  This is a concession to backwards
compatibility.

> So, the main difference with the current behaviour would be that
> 
> declare a='(1 2 3)'
> 
> or:
> 
> declare 'a=(1 2 3)'
> 
> or
> 
> declare a='([0]=a [1]=b)'
> 
> would not be an array (or hash) assignment if a was previously
> declared as a hash or array.

This is the other change.

> 
> declare -a a='(1 2)'
> 
> would still be but be deprecated in favour of:
> 
> declare -a a=(1 2)
> or
> declare a=(1 2)

I changed the output of `declare -p' to remove the single quotes around
the rhs of compound assignment statements to make the recommended syntax
a little more apparent.

Thanks for all the discussion about this.

Chet

-- 
``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/