From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7471 invoked from network); 15 Feb 2001 08:35:03 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Feb 2001 08:35:03 -0000 Received: (qmail 4627 invoked by alias); 15 Feb 2001 08:34:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13483 Received: (qmail 4606 invoked from network); 15 Feb 2001 08:34:56 -0000 From: "Bart Schaefer" Message-Id: <1010215083446.ZM9777@candle.brasslantern.com> Date: Thu, 15 Feb 2001 08:34:46 +0000 In-Reply-To: <000001c09716$fe7662e0$21c9ca95@mow.siemens.ru> Comments: In reply to "Andrej Borsenkow" "RE: More incompatibility :-) RE: PATCH: 3.1.9-dev-8: Re: Word splitting in zsh" (Feb 15, 9:17am) References: <000001c09716$fe7662e0$21c9ca95@mow.siemens.ru> X-Mailer: Z-Mail (5.0.0 30July97) To: "Zsh hackers list" Subject: Re: More incompatibility :-) RE: PATCH: 3.1.9-dev-8: Re: Word splitting in zsh MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 15, 9:17am, Andrej Borsenkow wrote: } Subject: RE: More incompatibility :-) RE: PATCH: 3.1.9-dev-8: Re: Word spl } } Ehh ... I did not mean it actually. My concern was that in ${=$(...)} } the `=' must not affect what happens inside of $(...). It could be argued either way. The doc says: Perform word splitting using the rules for SH_WORD_SPLIT during the evaluation of SPEC, but regardless of whether the parameter appears in double quotes; The $(...) is in fact part of SPEC. The problem is that, because ${=...} is not implemented by actually toggling SH_WORD_SPLIT, it's surprising what happens in cases like ${=x+$(setopt noshwordsplit; ...)}. } What I believe } should happen in case of ${x+${y}} - first, value is computed. It } is either $x or $y - without any wordsplitting. Then `=' is applied } to the result. What you've described is exactly what zsh does (withOUT my patch). This is what causes ${1+"$@"} to behave strangely: "$@" is expanded to an array, but then the elements of the result are subject to splitting, if splitting is enabled for the context (no matter why). My patch attempted to make it the responsibility of multsub() to do any splitting necessary on the right-hand-side of +/-, which works as long as the entire RHS is a parameter substition. However, In the case of ${1+some words "$@" more words}, prefork() [called by multsub()] just doesn't do enough: It yields "some words $1" ... "$@[-1] more words", where sh would give "some" "words" "$1" ... "$@[-1]" "more" "words". I've just about reached the conclusion that the RHS of these kinds of expansions will have to be re-lexed in order to be wordsplit properly. Once they've been lexed as a single word during the first pass, there is no provision for differentiating the quoted and unquoted substrings after expansion -- except within "nested" expansions, which doesn't cover all the possible cases. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net