From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1332 invoked from network); 7 Feb 2003 17:37:17 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 7 Feb 2003 17:37:17 -0000 Received: (qmail 5528 invoked by alias); 7 Feb 2003 17:36:53 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5891 Received: (qmail 5521 invoked from network); 7 Feb 2003 17:36:52 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 7 Feb 2003 17:36:52 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [62.189.183.235] by sunsite.dk (MessageWall 1.0.8) with SMTP; 7 Feb 2003 17:36:52 -0000 Received: from exchange01.csr.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 7 Feb 2003 17:43:19 +0000 Received: from csr.com (tinky-winky.csr.com [192.168.144.127]) by exchange01.csr.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DQ47LR2P; Fri, 7 Feb 2003 17:37:39 -0000 To: zsh-users@sunsite.dk Subject: Re: set -A In-reply-to: ""Bart Schaefer""'s message of "Fri, 07 Feb 2003 16:48:56 GMT." <1030207164856.ZM25338@candle.brasslantern.com> Date: Fri, 07 Feb 2003 17:36:53 +0000 Message-ID: <3703.1044639413@csr.com> From: Peter Stephenson "Bart Schaefer" wrote: > } But the `@' subscript is not documented to do anything useful for > } strings > > That's not strictly true. The docs say, in consecutive paragraphs: > > ---------- > A subscript of the form `[*]' or `[@]' evaluates to all elements of an > array; there is no difference between the two except when they appear > within double quotes. [...] > > Subscripting may also be performed on non-array values, in which case > the subscripts specify a substring to be extracted. > ---------- > > It does NOT say that subscripting non-array values is limited to using > integer ranges; it just says "subscripting may also be performed." The simple-minded reading would therefore be that the [@] has the same behaviour for strings as for arrays --- i.e. whether the parameter happens to be unset or not, and whether or not KSH_ARRAYS is in effect. Does that break anything if KSH_ARRAYS isn't set? (Presumably it doesn't break anything unless it relies on `undefined behaviour', hur hur. But I don't think we can be that sanguine about the zsh documentation, c.f. hitherto the undocumented set -A behaviour.) > It's actually worse than that, though, because ksh treats ALL parameters > as arrays -- in ksh, foo=xyz is the same as foo=(xyz) in zsh, and the > fiction of string variables is maintained by making $foo a reference to > ${foo[0]}. So when KSH_ARRAYS is set, ${foo[1]} (or any number greater > than zero) ought to produce an empty result when used on a scalar. Yes, that seems inevitable. -- Peter Stephenson Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. **********************************************************************