From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13044 invoked from network); 1 Jun 2001 13:40:28 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Jun 2001 13:40:28 -0000 Received: (qmail 2125 invoked by alias); 1 Jun 2001 13:40:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14645 Received: (qmail 2025 invoked from network); 1 Jun 2001 13:40:16 -0000 From: Sven Wischnowsky Date: Fri, 1 Jun 2001 15:39:16 +0200 (MET DST) Message-Id: <200106011339.PAA14041@beta.informatik.hu-berlin.de> To: zsh-workers@sunsite.dk Subject: Re: parameter substitution used in _values In-Reply-To: <3B179549.7B5A5519@u.genie.co.uk> Oliver Kiddle wrote: > Any ideas why the difference between using $1 and $a here below: > > % set -- '-Opath' > % a="$1" > % echo ${(@P)1[3,-1]} > 9XZfims > % echo ${(@P)a[3,-1]} > /usr/lib/jdk1.3/bin /usr/bin /bin ... etc ... > > I'm guessing that the 9XZfims is the list of single letter options but > why that and not the value of $path? This stuff is used at the beginning > of _values where it parses its options so it looks to me like _values > won't work with no space between -O and its argument. Oh rats. The problem is that the positional parameters are internally turned into `$argv[n]'. And, as one can see, % a=(-opath) % echo ${(@P)a[1][3,-1]} doesn't `work' either. The reason is that fetchvalue() applies only one subscript level, so the second fetchvalue() for the P flags doesn't get `path' in those cases. Obviously I wasn't aware of that and I don;t like it either, but see no simple fix (for the C-code). In the shell code we have to use `${(@P)${1[1,3]}}' for now. Oliver, if you have your hands in there anyway, could you? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de