Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
RE: More incompatibility :-) RE: PATCH: 3.1.9-dev-8: Re: Word splitting in zsh
- X-seq: zsh-workers 13479
- From: "Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>
- To: "Zsh hackers list" <zsh-workers@xxxxxxxxxx>
- Subject: RE: More incompatibility :-) RE: PATCH: 3.1.9-dev-8: Re: Word splitting in zsh
- Date: Thu, 15 Feb 2001 09:17:38 +0300
- Importance: Normal
- In-reply-to: <Tc0a8890c51ba890230@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
>
> > 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.
>
> I'd go for the original patch, plus (1). Almost certainly if there are
> side effects we won't find out until the patch is in place anyway.
>
Ehh ... I did not mean it actually. My concern was that in ${=$(...)} the `='
must not affect what happens inside of $(...). 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. It is different from
just turning wordsplitting on - consider ${=${${foo}[2]}} where foo is array.
Here internal ${foo} should not be wordsplitted, else it is hard to get
predictable result.
-andrej
Messages sorted by:
Reverse Date,
Date,
Thread,
Author