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

[emanuelczirai]

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. :)
I just hope nobody is going to try to exploit it or something.

That segfault though:
set -x
declare -A ar
key='`echo -n "1">>times.txt`'
((++ar[$key])) # cmd in $key gets executed twice too
declare -p ar

$ ./b.bash
./b.bash:5+ declare -A ar
./b.bash:6+ key='`echo -n "1">>times.txt`'
./b.bash:7+ (( ++ar[`echo -n "1">>times.txt`] ))
../b.bash:7+ echo -n 1
./b.bash: line 7: ar: bad array subscript
../b.bash:7+ echo -n 1
./b.bash: line 7: ar[`echo -n "1">>times.txt`]: bad array subscript
Segmentation fault (core dumped)

Disclaimer: I have stumbled upon this "non-issue" by mistake and I've no 
intention of exploiting anything ('cause I got principles, heh; 
seriously though)
Ok bye.

PS: this still makes me sad though :')

On 2015-02-18 20:14, Chet Ramey wrote:
> On 2/16/15 12:23 PM, emanuelczirai@cryptolab.net wrote:
> > Oh I see, I had no idea that's how it's meant to work. My apologies.
> >
> > However this case still doesn't work, but maybe I should use single 
> > quotes
> > all the time?:
> >
> > this fails(double quotes):
> > $ declare -A ar
> > $ idbad2="["
> > $ let "ar[$idbad2]+=11"
> > bash: let: ar[[]+=11: bad array subscript (error token is "ar[[]+=11")
> > $ declare -p ar
> > bash: declare: ar: not found
>
> Bash expects the brackets to match.  This is true when the parser tries 
> to
> find the closing bracket and when the arithmetic expression evaluator
> does -- they use the same criteria.  You can make a case that they 
> should
> not have to match, but bash has always behaved this way and you'll have 
> to
> work with it, at least for now.
>
> > this works(single quotes):
> > $ let 'ar[$idbad2]+=11'
> > $ declare -p ar
> > declare -A ar='(["["]="11" )'
>
> This works because the arithmetic expression evaluator doesn't have to
> deal with the extra `[' when trying to find the end of the subscript, 
> and
> it's smart enough to figure out whether it's dealing with an indexed or
> associative array and evaluate accordingly.
>
> > also this variant does the same:
>
> Because (( and let are essentially equivalent.
>
> Chet