From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28665 invoked from network); 17 Mar 1999 10:01:16 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Mar 1999 10:01:16 -0000 Received: (qmail 9364 invoked by alias); 17 Mar 1999 10:00:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5839 Received: (qmail 9348 invoked from network); 17 Mar 1999 10:00:37 -0000 From: "Andrej Borsenkow" To: "Sven Wischnowsky" , Subject: RE: PATCH: param stuff and was: PATCH: 3.1.5-pws-12: _brace_parameter Date: Wed, 17 Mar 1999 12:59:19 +0300 Message-ID: <006201be705c$d3291660$21c9ca95@mowp.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <199903170909.KAA26801@beta.informatik.hu-berlin.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 > > This ounds good, but can't be done easily (I think). The problem is > that in the case of a `${${...}...}' the code currently just takes the > inner `${...}' and calls `prefork()' on it (which does most of the > expansions). The result is a list of strings and no other > information. So here, the result of an one-element array and an scalar > is indistinguishable. This means that we have to say in the *outer* > `${...}' if we want the result of the inner one to be treated as an array. > Can I formulate it as: every substitution is done as if it were the top-level one? > > The problem is that this is even more uncompatible with previous > version than what we have now. > The problem ZSH always had (and have) is very poor documentation. I think, the (partial) reason for it is, nobody actually knows, how it behaves. New features are added on ad-hoc basis, without clear picture, how the whole works. Currently there are several ZSH wizards that either know all ins and outs by heart or know source code. It is virtually impossible for ordinary user to use the power ZSH provides, because the only way to do it is by trial and error. You never can tell, what is a result of a (mildly complicated) expression simply by looking at it. Can anybody explain (in the manual) how ZSH substitution really works? Returning to my example: bor@itsrm2:~%> foo=(bar baz) bor@itsrm2:~%> print "${(@)${foo}[1]}" bar baz bor@itsrm2:~%> print "${${(@)foo}[1]}" b Could anybody explain, why? We take the value of foo, that is (bar baz). The whole is quoted, so it is converted to scalar. Then, all of a sudden, this scalar is converted back to array! Why? What about second? On the top level, (@) prevents array->scalar converting: bor@itsrm2:~%> print -l "${(@)foo}" bar baz But why it does not happen with inner ${(@)foo} in the above case? How can I take array slice in double quotes? That is only one example of inconsistency. The answer "it is implemented this way" is very weak argument. What I'd like to hear - *why* is it implemented this way. We already had a long shot at RC_EXPAND_PARAM. Yes, it was incompatible with previous version - but it made RC_EXPAND_PARAM finally useful - and *predictable*. What I'd like to see in parameter expansion - it is predictability. cheers /andrej