From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21348 invoked from network); 1 Aug 1997 13:25:46 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 1 Aug 1997 13:25:46 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.8.5/8.8.5) id JAA01614; Fri, 1 Aug 1997 09:17:49 -0400 (EDT) Resent-Date: Fri, 1 Aug 1997 09:17:49 -0400 (EDT) Date: Fri, 1 Aug 1997 17:17:17 +0400 (MSD) From: Andrej Borsenkow X-Sender: bor@itsrm1 Reply-To: borsenkow.msk@sni.de To: Bart Schaefer cc: Andrew Main , zsh-workers@math.gatech.edu Subject: Re: RC_EXPAND_PARAM bug In-Reply-To: <970730100516.ZM22270@candle.brasslantern.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"4Idk02.0.9P.y7Uup"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3401 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Wed, 30 Jul 1997, Bart Schaefer wrote: > > I think the beta16-and-earlier cartesian product was reasonable and gave > consistent results. However, I encourage a warning in the doc that the > results are not the same as for rc and that mixing ${^x} and ${^^x} in > the same word may not behave in the way one expects. > There is probably one more alternative, but let me first explain how I understand the problem. /bin/sh (and POSIX sh) rules are based on textual substitution. They are very simple and consist of well defined steps: 1. break line into sequence of substitutions 2. evaluate each of them 3. concatenate results 4. break result in words with field splitting ZSH coompicates it by adding arrays. They can still fit in above scheme, if we define what $array means. ZSH defines it as "$array[@]" which is quite acceptable (I don't speak about implementation; I understand, arrays are actually implemented as lists internally). RC_EXAPND_PRAMS is based on absolutely different assumption. Original implementation (rc) operates on _lists_, and is using _binary operator_ and not plain substitution/concatenation. The '$a$b' in rc is just shorthand for '$a^$b' where `^' is binary opereator (wether pairwise or cartesian product doesn't actually matters). rc just cannot have our problems, because it is driven by usual operator precednce rules. Both implemetations (pre-beta16 and current) actually do the following: - break word into ^- and non-^-parts - do substitutions on non-^-parts (and on nested substitions in ^-parts) based on traditional (textual) rules - convert results into lists (implicit field-splitting) - combine the lists They differ just in how lists are combined: pre-beta16 treats `^' as ternary operator: xx$^ayy -> xx^$a^yy (in rc notation) current treats `^' as binary operator with right precedence: xx$^ayy -> xx($a^y) Both is acceptable as long as it is documented ;) Correct me, if I am wrong. Now, if the above rules are explicitly stated in ZSH docs it is enough. It will enable users to understand what's really going on, which is very hard to do now ;-} I suggest, that zshexpn(1) explicitly states this additional step and how it works (FAQ could then give some examples). The same holds true for brace expansion as well (which is currently done differently from RC_EXPNAD_PARAM). Oh, I almost forgot my proposal ... - get rid of ^ as subst modifier - use explicit operator notation; something like ${prefix^suffix}, where prefix and suffix are expanded, converted to lists and combined. The result is then stuffed in replaced string in usual manner (as if it were array - which by the way it is ;) We could include operator precedence so that ${xxx^yyy^zzz} could be used. I am not shure if current grammar permits use of `^' in this case, but I still like the idea ... ------------------------------------------------------------------------- Andrej Borsenkow Fax: +7 (095) 252 01 05 SNI ITS Moscow Tel: +7 (095) 252 13 88 NERV: borsenkow.msk E-Mail: borsenkow.msk@sni.de -------------------------------------------------------------------------