Re: array subscripts act differently for integers(ie. let)

[Dan Douglas]

On Thu, Feb 19, 2015 at 7:47 PM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 2/18/15 4:14 PM, emanuelczirai@cryptolab.net wrote:
>> tl;dr: thanks! no reply needed;
>>
>> Thanks guys. I had a hard time accepting that this is how it's supposed to
>> work.
>> I accepted it now. :)
>
> Yeah.  The expression between (( and )) is word expanded, since (( ... ))
> is supposed to be exactly equivalent to let "...".
>
> The real issue is that assignment statements in arithmetic expressions
> that contain array references are also word expanded, almost as if they
> were executed in an assignment statement context.  This is how bash has
> always behaved, though; backwards compatibility is a concern.

The way bash works right now allows safely handling arbitrary
associative array keys. This is a pretty good illustration:

$ bash -c 'key=\]; typeset -A a=([$key]=x [y]=y); unset -v
"a[\${key}]"; typeset -p a'
declare -A a='([y]="y" )'
$ ksh -c 'key=\]; typeset -A a=([$key]=x [y]=y); unset -v
"a[\${key}]"; typeset -p a'
typeset -A a=([']']=x [y]=y)

Since ksh doesn't do parameter expansion while resolving variables
quite consistently it's impossible to handle this case. (I'll have to
ask about it on their list one of these days).

IMO bash is exactly correct. I don't know how this could be "fixed" in
a way that would satisfy people without changing something very
fundamental. If you disable the initial expansion to `(())', then
`(($x))' wouldn't work (because arithmetic evaluation doesn't itself
evaluate parameter expansions). However if you disabled evaluating
parameter expansions during variable resolution (for array indexes)
then you would be stuck with exactly the above ksh problem.

It's unfortunate people don't understand this, but when you think
about it it can't really work any other way.

-- 
Dan Douglas