From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8981 invoked from network); 9 Mar 2004 09:58:51 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 9 Mar 2004 09:58:51 -0000 Received: (qmail 23006 invoked by alias); 9 Mar 2004 09:58:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19572 Received: (qmail 22979 invoked from network); 9 Mar 2004 09:58:43 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 9 Mar 2004 09:58:43 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [193.109.254.211] by sunsite.dk (MessageWall 1.0.8) with SMTP; 9 Mar 2004 9:58:42 -0000 X-VirusChecked: Checked X-Env-Sender: okiddle@yahoo.co.uk X-Msg-Ref: server-19.tower-36.messagelabs.com!1078826321!4496128 X-StarScan-Version: 5.2.5; banners=-,-,- X-Originating-IP: [158.234.9.163] Received: (qmail 31801 invoked from network); 9 Mar 2004 09:58:41 -0000 Received: from iris.logica.co.uk (158.234.9.163) by server-19.tower-36.messagelabs.com with SMTP; 9 Mar 2004 09:58:41 -0000 Received: from trentino.logica.co.uk ([158.234.142.61]) by iris.logica.co.uk (8.12.3/8.12.3/Debian -4) with ESMTP id i299wfCk005438 for ; Tue, 9 Mar 2004 09:58:41 GMT Received: from trentino.logica.co.uk (localhost [127.0.0.1]) by trentino.logica.co.uk (Postfix) with ESMTP id E50AC79721B9 for ; Tue, 9 Mar 2004 10:57:56 +0100 (CET) X-VirusChecked: Checked X-StarScan-Version: 5.0.7; banners=.,-,- In-reply-to: <1040308221959.ZM13999@candle.brasslantern.com> From: Oliver Kiddle References: <20040308152325.GB9385@scowler.net> <1040308221959.ZM13999@candle.brasslantern.com> To: zsh-workers@sunsite.dk Subject: Re: [frederik@ugcs.caltech.edu: Bug#236748: zsh: associative array documentation reference broken] Date: Tue, 09 Mar 2004 10:57:56 +0100 Message-ID: <26321.1078826276@trentino.logica.co.uk> Bart wrote: > On Mar 8, 10:23am, Clint Adams wrote: > } > } For associative arrays, `[*]' or `[@]' evaluate to all the values > } (not the keys, but see Subscript Flags below), in no particular > } order. > } > } There is nothing relevant to this syntax under Subscript Flags. > > Yes, there is. The k, K, and e subscript flags all affect the > intepretation of * and @. It's true that [(K)*] is nearly the same > as [*], but [(k)*] is quite different, as both [(k)@] and [(K)@] are > from [@]. Yes, I mentioned this in the original thread (http://bugs.debian.org/236748), though I didn't check which flags apply. > } For associative arrays, `[*]' or `[@]' evaluate to all the values > } (not the keys, but see the documentation for the 'k' flag under > } Parameter Expansion Flags in zshexpn(1)), in no particular order. > > No, this is NOT what it should say, or at least not ALL that it should > say. I think the change as currently proposed is an improvement because it is far easier to remember (k) and (v) as the way to control whether keys or values are output. So the emphasis should be on the expansion flag but it might be useful to mention the subscript flags too. I've been meaning to make (k) and (kv) work for normal arrays too. The subscript flags do too many different things which makes them complicated to remember. Whether things can be changed in a backward compatible way, I don't know but in any case changes would probably need the long overdue parameter code rewrite. I'll bore you with my thoughts anyway. The only unique feature the subscript flags offer is the ability to do reverse subscripting (i.e. looking things up by value instead of key) and to use pattern matching instead of exact string matches. Those two features require just two flags (and even the latter is very similar to ${var:#pat}). We have (k) and (v) flags to control what is returned and if an array of results is returned, subsequent array indexing such as [1] and [-1] would replace the abilities of (i) and (I) to return just highest and lowest values. That'd be easier to read and easier to remember at the expense of being more to type. Oliver