From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13614 invoked from network); 28 Sep 1999 12:59:55 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 Sep 1999 12:59:55 -0000 Received: (qmail 13970 invoked by alias); 28 Sep 1999 12:51:20 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8085 Received: (qmail 13963 invoked from network); 28 Sep 1999 12:51:19 -0000 Message-Id: <9909281215.AA16286@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: assoc array assignment problem. In-Reply-To: ""Bart Schaefer""'s message of "Tue, 21 Sep 1999 04:59:34 DFT." <990921045934.ZM13380@candle.brasslantern.com> Date: Tue, 28 Sep 1999 14:15:43 +0200 From: Peter Stephenson "Bart Schaefer" wrote: > } 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. Two comments: - addvars() is performing an initial substitution on the LHS, but the parameter expansion code isn't; with $q[$f], nothing gets substituted until the look up for q[$f] on hitting the first `$'. I don't see why addvars() needs to do that initial substitution, though: in the old days, you could do `foo=bar; $foo=something' to set bar, but now you can't. So I suspect that first substitution may be redundant, and that all substitution should be delayed until the parameter code, as it is when a parameter is being used rather than asssigned. However, this does untokenize the name, which maybe partly explains the following behaviour. - The weirdest thing seems to me to be that getindex() is untokenizing the [...] part, only for it to be retokenized again down in getarg(). This can't be right, can it? It would be far better if what getindex() gets is correctly tokenized according to whether or not you want it substituted (including not untokenizing it in addvars()), and if that was respected this problem would go away. That should be OK, because the subscript should already be tokenized in just the same way as the parameter expansion. Shouldn't it? - (three comments, among the comments are): Looking at addvars(), it seems that the following (with no existing $foo): setopt restricted foo=bar cat /dev/null could be bad for business, but AIX is unable even to give me the satisfaction of a core dump. I get fed up with this shell sometimes. Maybe I'll take a look at this, but I'd prefer to retreat into a hole in the ground. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy