Re: assoc array assignment problem.

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sep 21, 10:37am, Tanaka Akira wrote:
} Subject: assoc array assignment problem.
}
} Z(2):akr@localhost% Src/zsh -f
} localhost% typeset -A arr
} localhost% a='$b'
} localhost% b='c'
} localhost% arr[$a]=d
} localhost% print -lr - ${(kv)arr}
} c
} d
} localhost% 
} 
} Hm. Variable expansion is performed twice.

This is not an associative array problem; it affects all arrays.  Note:

zagzig<17> q=()
zagzig<18> g=7
zagzig<19> f='$g'
zagzig<20> q[$f]=seven
zagzig<21> print $#q $q
7 seven
zagzig<22>

The first substitution happens at the expected time, during evaluation
of the line.  The second one happens at execute time in addvars() --
assignment is implemented as if `x=y somecommand` where somecommand is
null.  addvars() calls setsparam(), which discovers that there is no
parameter named "q[$g]" and therefore creates "q" and then makes a call
to getvalue() to retrieve a Value structure for the parameter that it
just created.  getvalue() then expands $g (as it would for ${q[$g]} in
which the stuff inside the ${ } has _not_ previously been expanded) and
you get the effect above.

And you can't even protect it with double-quoting, though using single
quotes counterintuitively (but expectedly, given the explaination above)
produces the desired result:

zagzig<26> arr['$a']=d
zagzig<27> print -lr - ${(kv)arr}
$x
d
zagzig<28>

I really have no idea when this got introduced.  It might have something
to do with zsh-workers/4826 and follow-ons, back last year; 3.1.5-pws-4
would be it, but I no longer have anything that old around to try.

The right thing would be for the parser to know that it shouldn't expand
inside the [] on the left-hand side of an assignment, thereby delaying
the one interesting expansion to getvalue(); but that may be a bit too
much to bite off ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com