On 12/16/14 4:49 PM, Stephane Chazelas wrote:
> I believe my proposal in Message-ID:
> <20141214204845.ga5...@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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
