From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17307 invoked by alias); 20 Nov 2010 22:00:32 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28425 Received: (qmail 15210 invoked from network); 20 Nov 2010 22:00:28 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at ntlworld.com designates 81.103.221.58 as permitted sender) Date: Sat, 20 Nov 2010 21:15:28 +0000 From: Peter Stephenson To: zsh-workers@zsh.org (Zsh hackers list) Subject: Re: PATCH: bash-style substrings & subarrays Message-ID: <20101120211528.0caf8697@pws-pc.ntlworld.com> In-Reply-To: <101119100147.ZM4622@torch.brasslantern.com> References: <27165.1290012857@csr.com> <101119100147.ZM4622@torch.brasslantern.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Cloudmark-Analysis: v=1.1 cv=X0sWjjQ37bMP4yB/pNNinY3VxVB2n/hmdAjhihaCFGs= c=1 sm=0 a=KG8k_i-9y-sA:10 a=IkcTkHD0fZMA:10 a=q2GGsy2AAAAA:8 a=NLZqzBF-AAAA:8 a=VNoIctcbNs1ZBRLcDcsA:9 a=IGi83XzVM2UcEOJrn1sA:7 a=s1pbT-fhkwujjohz0SboSxcFlb4A:4 a=QEXdDO2ut3YA:10 a=I6wTmPyJxzYA:10 a=_dQi-Dcv4p4A:10 a=jmyKrBqIUVO4hPPn:21 a=6pU2p5pJdjKOq5WG:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 On Fri, 19 Nov 2010 10:01:45 -0800 Bart Schaefer wrote: > On Nov 17, 4:54pm, Peter Stephenson wrote: > } > } This implements the ${NAME:OFFSET} and ${NAME:OFFSET:LENGTH} syntax. > } This is basically for compatibility; we don't need the extra > } functionality, but it's a syntax people are nowadays assuming they can > } use. >=20 > I'm wondering whether :OFFSET:LENGTH shouldn't always use KSH_ARRAYS > semantics, or be a valid syntax only when KSH_ARRAYS is set? If it's > for compatibility with people who are assuming it works, those people > are also going to assume it has zero-offset, aren't they? I can see that if you interpret the word "OFFSET" literally it's different from a subscript and you might interpret it as starting from 0 in any case. I still think on balance consistency with normal subscripting is preferable. I don't think half-measures compatibility with other shells is particularly useful, in the end is probably more confusing when you find some things work the way you expect and some things don't. However, with a stress in the documentation on the fact that it's an offset, not a subscript, I can see there's an argument for the other way. > There may be some error cases not yet caught: >=20 > schaefer<508> foo=3D123456789 > schaefer<509> unset y x > schaefer<510> echo ${foo:$y:$x}=20 > zsh: bad math expression: illegal character: =C3=9D >=20 > That =C3=9D looks like uninitialized memory garbage. It's the fact that empty strings turn into Nularg. I should be tidying up the string after the expansion. After the patch empty expansions evalua= te to 0, consistent with the effect of=20 % print $(( )) 0 Index: Src/subst.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/zsh/zsh/Src/subst.c,v retrieving revision 1.110 diff -p -u -r1.110 subst.c --- Src/subst.c 18 Nov 2010 13:57:19 -0000 1.110 +++ Src/subst.c 20 Nov 2010 20:58:22 -0000 @@ -1403,6 +1403,8 @@ check_colon_subscript(char *str, char ** if (parsestr(str =3D dupstring(str))) return NULL; singsub(&str); + remnulargs(str); + untokenize(str); =20 **endp =3D sav; return str; --=20 Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/