From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5766 invoked from network); 15 Apr 1999 06:50:07 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Apr 1999 06:50:07 -0000 Received: (qmail 16857 invoked by alias); 15 Apr 1999 06:49:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6041 Received: (qmail 16850 invoked from network); 15 Apr 1999 06:49:57 -0000 Date: Thu, 15 Apr 1999 08:49:55 +0200 (MET DST) Message-Id: <199904150649.IAA01607@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Wed, 14 Apr 1999 10:27:51 -0700 Subject: Re: BUG: zsh-3.1.5-pws-14: parameter expansion not working properly Bart Schaefer wrote: > Now that I've seen/used it in practice a few times, I'm not so sure any > more. The more radical change, and one which bothers me a lot, is the > effect when the array has more than one element: > > foo=(xa yb zc) > print -l "${${(@)foo}[1]}" "${(@)${foo}[1]}" > > Zsh 3.0.5 prints > > xa > x > > But 3.1.5-pws-14 prints > > x > xa > > That's completely reversed the semantics, and thus is a serious problem. (Do you really get `xa' in the last case?) This (and the need to repeat the `(@)') comes from the fact that multsub() doesn't get any information about where the words came from. I.e. if they are an `array' (even if only one string) or not. I already said this at least once. To solve this better we would need a way to make `paramsubst()' notify `multsub()' if the thing is an array. This could be done by using a subst.c-global variable that is set in multsub() and paramsubst() and tested in multsub() after prefork(), of course. And then we would have to decide when we want to accept an array at the call of multsub(). Always, if the sub-expression is an array? Even if the whole thing is in double quotes? If it is in double quotes and we don't want it always, when? Hm, maybe when the `(@)' flag is given or the things came from an array. But then there would be no way to make an array be treated as a scalar further down up then by using the `(j:...:)' flag. But then again, this may be ok. Or maybe we make the inner expression be taken as an array if it is a parameter expansion that results in an array and make it be used as a scalar value in all other cases, independent of quoting (which means that the quoting will only have it's normal effect on the inner expressions). That way the `(@)' has only an effect to the `outside', not on the treatment of an inner expression when given in an outer one (something I already described -- and didn't like, too). This would give the same as 3.0.5 again for your example above, with the `x' returned as an array, which noone will notice (and the `(@)' wouldn't have any effect in `"${(@)${foo}[1]}"'). There may be other problems I don't see, though (apart from changing the manual again). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de