From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15160 invoked from network); 13 Feb 2001 19:43:05 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Feb 2001 19:43:05 -0000 Received: (qmail 11089 invoked by alias); 13 Feb 2001 19:42:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13468 Received: (qmail 11070 invoked from network); 13 Feb 2001 19:42:56 -0000 From: "Bart Schaefer" Message-Id: <010213113312.ZM27482@candle.brasslantern.com> Date: Tue, 13 Feb 2001 11:33:12 -0800 In-Reply-To: <001601c095a3$63928b10$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 13, 12:57pm) References: <001601c095a3$63928b10$21c9ca95@mow.siemens.ru> X-Mailer: Z-Mail Lite (5.0.0 30July97) To: "Andrej Borsenkow" , 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 13, 12:57pm, Andrej Borsenkow wrote: > Subject: RE: More incompatibility :-) RE: PATCH: 3.1.9-dev-8: Re: Word spl > > > print ${=foo+"$(unsetopt shwordsplit;print -l $bar)"} > > > > actually *does* split the value of $bar within the command subst. Hmm. > > Yep. That is exactly what I meant. I'm not sure what is current > status, but I always assumed that any flag applies to current value > only and not propagates to nested substitutions. At least this sounds > logical. Depends on what you mean by "nested substitutions." Without my patch, the flag effectively applies to all nested substitutions because splitting is done again at each level *after* the value propagates up from the any nested substitution. With my patch, for exactly the ${x+y} and ${x-y} cases, the current state of splitting is deliberately propagated to the right-hand-side, which is not so much a nested substitution as it is a "alternate" substitution. However, the way that I propagated it causes it to override `setopt' for the shwordsplit option, which is correct in the current shell but not in subshells i.e. $(...). The two possible solutions to this are (1) make ${=...} behave the way Andrej says is "logical", so that e.g. with shwordsplit turned off, in ${=x+${y}} no word splitting would happen at all (because it's not on in $y, even though it's on for $x; or (2) figure out how to reset the value of mult_spbreak to 0 during $(...) (mult_shwsplit is ignored if mult_spbreak is 0). (1) actually means removing mult_spbreak and mult_shwsplit entirely; I put them in because I thought to do otherwise would be too great a behavior change from the way zsh works without the patch.