From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk (Zsh hackers list)
Subject: Re: PATCH: pws-19: document minor syntactic innovation
Date: Tue, 1 Jun 1999 17:44:32 +0000 [thread overview]
Message-ID: <990601174432.ZM11100@candle.brasslantern.com> (raw)
In-Reply-To: <9906010956.AA18502@ibmth.df.unipi.it>
On Jun 1, 11:56am, Peter Stephenson wrote:
} Subject: PATCH: pws-19: document minor syntactic innovation
}
} I should note that things like ${"foo"} only work by accident: you'll find,
} for example, that ${"foo"%bar} doesn't work. That would require swallowing
} nulled out quotes at another point in paramsubst(), which I hinted at
} before. I didn't do this because I didn't see a use for it, but maybe it's
} more consistent that way?
If it's messy, I think it could be left out, but yes, it is more consistent
that way.
} > What's the right way to document this change, including odd stuff like
} > the above?
}
} Here's a possible chunk for 3.1.5-pws-20.
[...]
} +Note that double quotes may appear around nested quotations, in which case
Perhaps "nested expansions" rather than "nested quotations"?
} > Should the FAQ recommend using this form in some circumstances because
} > of the (@) change in 3.1.5?
}
} Well, the new nested substitution section (3.22) is really about getting a
} parameter evaluated as a parameter name and I'm not sure it's a good idea
} to put in a lot of stuff about other flags and their uses, which could get
} quite involved. Maybe it needs a separate question, but I'm not sure I can
} even remember the full effect of the changes.
The full effect of the (@) changes? It's pretty simple, really. In 3.0,
once something becomes an array as a result of (@) or (f) or (s//), it is
always an array, even inside quotes, no matter how deeply nested the ${ }
get. In 3.1.5-pws-XX for XX > 15 (I think it was), array-ness persists
only for the current level of ${ }; if there's another ${ } around that,
quoted-ness takes over again.
So to get certain quoted array expansions to behave the same in 3.0.6 and
3.1.5-pws-20+, you must either put in an (@) at every ${ } (which is ugly
and, in 3.0.6, redundant), or you must `push in the quotes' as deeply into
the nested ${ } as possible, e.g. to immediately surround the ${(@)...}.
For example, in 3.0.6-pre-4 and later, the following all are (will be)
equivalent:
"${${${(f)$(print -l *)}}}" (1)
${"${${(f)$(print -l *)}}"} (2)
${${"${(f)$(print -l *)}"}} (3)
${${${(f)"$(print -l *)"}}} (4)
In 3.1.5-pws-20, (1) == (2) [both are strings] and (3) == (4) [both are
arrays], but [obviously] (1) != (4).
Oh, and of course the [@] subscript and subscript number ranges behave
just like the (@) flag as far as this is concerned.
I admit I haven't worked out whether there are other ramifications when
SH_WORD_SPLIT is set ....
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1999-06-01 17:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-05-23 15:15 PATCH: pws-19: " Peter Stephenson
1999-05-29 8:31 ` Bart Schaefer
1999-05-31 22:41 ` Bart Schaefer
1999-06-01 6:23 ` Andrej Borsenkow
1999-06-01 8:21 ` Peter Stephenson
1999-06-01 12:52 ` Andrej Borsenkow
1999-06-01 9:56 ` PATCH: pws-19: document " Peter Stephenson
1999-06-01 17:44 ` Bart Schaefer [this message]
1999-06-02 8:03 ` Peter Stephenson
1999-06-02 8:44 ` sh compatibility " Andrej Borsenkow
1999-06-02 8:30 ` Peter Stephenson
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=990601174432.ZM11100@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.auc.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).