From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11146 invoked from network); 26 Jul 2001 17:52:52 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Jul 2001 17:52:52 -0000 Received: (qmail 13669 invoked by alias); 26 Jul 2001 17:52:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15506 Received: (qmail 13657 invoked from network); 26 Jul 2001 17:52:43 -0000 From: "Bart Schaefer" Message-Id: <1010726174930.ZM23256@candle.brasslantern.com> Date: Thu, 26 Jul 2001 17:49:30 +0000 References: <1010726051301.ZM19183@candle.brasslantern.com> <001b01c115b5$657254a0$21c9ca95@mow.siemens.ru> <001f01c115b9$72dec660$21c9ca95@mow.siemens.ru> <3B5FEB29.884D31BF@u.genie.co.uk> <3B5FF9F1.5171AC7D@u.genie.co.uk> <002001c115c3$524f76b0$21c9ca95@mow.siemens.ru> <002101c115c4$a7d768d0$21c9ca95@mow.siemens.ru> <3B60012C.EF6E906A@u.genie.co.uk> <000001c115d6$50e082c0$21c9ca95@mow.siemens.ru> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.dk Subject: Re: Nasty bug in array-element typeset assignments MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Good grief, this is the most discussion on a single topic in weeks. I shouldn't have gone to bed last night, I guess. On Jul 26, 10:44am, Peter Stephenson wrote: } } When you add to this the restore sequence, which is handled at the } end of function scope with no detailed knowledge of what typeset has been } up to, you've got something very difficult to maintain It's not supposed to create a local *element*, it's just supposed to assign to an element of a local array. On Jul 26, 1:57pm, Borsenkow Andrej wrote: } } BTW it is allowed in 4.0.2, I do not have earlier versions here readily } available. May be, it was always possible? See 14060, as Andrej already mentioned -- it was always possible, but badly broken. It seemed useful to me, so I tried to fix it rather than prevent it. I discovered the bug when writing this: function example() { local 'new_array[$#new_array+1]'=$^old_array # ... } The above works beautifully, and is equivalent to what you'd get if the syntax `local new_array=( $old_array )' worked. In fact, the following also works, and does not cause a core dump: function example() { local path 'path[$#path+1]'=$^path # ... } Because in the above statement, `path' is made local before the elements are assigned. Et voila. On Jul 26, 12:07pm, Oliver Kiddle wrote: } } I wrote: } > However, I wouldnt have thought it'd be too } > hard to get it to print an error message for the above case. } } This might be useful for 4.0.2 so the following is a patch to do that } much. There was never any patch following ... but that's just as well, because I don't want to print an error in this case, unless possibly the array is non-local. On Jul 26, 12:38pm, Oliver Kiddle wrote: } } > Probably, intent was to create new local array. } } Urgh. Is that really that useful? It's really useful (see above), but it's not really necessary (also see above). } Also, if this is fixed to make the whole array local but the fix is } complicated then this small change might be a good option for the 4.0 } branch. I think there's a simple fix we can do without disallowing it entirely. On Jul 26, 12:45pm, Peter Stephenson wrote: } } Something like that would definitely be my preference. I have something working that's actually a very small change, and still permits my second example above to work (while rejecting the first one). Let me play with a few more cases so I can put the right regression tests in D06 -- it'll probably be several hours before I get to concentrate on it. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net