From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: "Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>,
<zsh-workers@sunsite.dk>
Subject: Re: More incompatibility :-) RE: PATCH: 3.1.9-dev-8: Re: Word splitting in zsh
Date: Tue, 13 Feb 2001 11:33:12 -0800 [thread overview]
Message-ID: <010213113312.ZM27482@candle.brasslantern.com> (raw)
In-Reply-To: <001601c095a3$63928b10$21c9ca95@mow.siemens.ru>
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.
next prev parent reply other threads:[~2001-02-13 19:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <000d01c0926a$ce26c590$21c9ca95@mow.siemens.ru>
2001-02-09 18:18 ` Bart Schaefer
2001-02-10 20:24 ` PATCH: 3.1.9-dev-8: " Bart Schaefer
2001-02-12 7:38 ` Andrej Borsenkow
2001-02-12 14:12 ` Andrej Borsenkow
2001-02-12 19:38 ` Bart Schaefer
2001-02-13 7:51 ` More incompatibility :-) " Andrej Borsenkow
2001-02-13 9:26 ` Bart Schaefer
2001-02-13 9:57 ` Andrej Borsenkow
2001-02-13 19:33 ` Bart Schaefer [this message]
2001-02-14 18:00 ` Peter Stephenson
2001-02-15 6:17 ` Andrej Borsenkow
2001-02-15 8:34 ` Bart Schaefer
2001-02-15 10:35 ` More incompatibility (word splitting) Peter Stephenson
2001-02-16 7:43 ` PATCH: " Bart Schaefer
2001-02-16 8:50 ` Andrej Borsenkow
2001-02-16 17:03 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=010213113312.ZM27482@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=Andrej.Borsenkow@mow.siemens.ru \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).