From: Bart Schaefer <schaefer@brasslantern.com>
To: dana <dana@dana.is>
Cc: Sebastian Gniazdowski <sgniazdowski@gmail.com>,
"zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: Inconsistencies in "-quoting and @-splitting, could someone elaborate?
Date: Sat, 27 Oct 2018 21:54:11 -0700 [thread overview]
Message-ID: <CAH+w=7Z8cA5e=9YLCUT0hCM=ZU73DrO5bgxWpRLqW+ZMviQBLw@mail.gmail.com> (raw)
In-Reply-To: <1BE52C46-161F-412B-A539-4B0EA87A2FCE@dana.is>
On Sat, Oct 27, 2018 at 5:34 PM dana <dana@dana.is> wrote:
>
> On 27 Oct 2018, at 05:33, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> >I'm having problem in grasping, is this behavior:
> >- "X-flag creates array, unless its result is a single element", and
> >- "X-flag creates array even when double quoted without use of @"
>
> I don't know if it's accurate to say that they 'create an array' — they expand
> to a list of zero, one, or multiple words (or elements, or arguments, or
> whatever you want to call them), which you might then *put into* or (in certain
> parameter-expansion cases) *act on as* an array, but the result of the expansion
> is not an array per se.
You're not wrong, but the documentation consistently refers to a word
list occuring in parameter expansion context as "an array".
To address Sebastian's question, the behavior of (s::) is historical.
Because zsh passes expansions around by value rather than by
reference, in the original implementation of nested expansions a
single-element array value was indistinguishable from a scalar. This
didn't change until 2015, when extra effort was made to retain the
properties of a parameter across levels of nested expansion. However,
the result of a split with (s::) is never a parameter (it's just an
array value), so it kept the old behavior. This is true of anything
that is considered "simple word splitting" (#11 in the "Rules"
subsection of the parameter expansion docs), and also of the (z::)
operation (rule #17). However, you'll never see the effect unless the
array value is inside a nested expansion; if there is only a single
level of expansion, double-quotes (rule #5) apply before splitting, so
the result remains an array.
To circumvent this historical behavior, the (@) and (A) flags are used
to propagate array interpretation from an inner nesting to an outer
one.
next prev parent reply other threads:[~2018-10-28 4:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-27 10:33 Sebastian Gniazdowski
2018-10-28 0:34 ` dana
2018-10-28 4:54 ` Bart Schaefer [this message]
2018-10-28 11:54 ` Sebastian Gniazdowski
2018-10-28 15:41 ` Sebastian Gniazdowski
2018-10-28 15:45 ` Sebastian Gniazdowski
2018-10-28 21:20 ` Bart Schaefer
2018-10-28 21:12 ` Bart Schaefer
2018-10-29 9:10 ` Sebastian Gniazdowski
2018-10-29 15:24 ` Bart Schaefer
2018-11-05 19:03 ` Sebastian Gniazdowski
2018-11-05 23:20 ` 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='CAH+w=7Z8cA5e=9YLCUT0hCM=ZU73DrO5bgxWpRLqW+ZMviQBLw@mail.gmail.com' \
--to=schaefer@brasslantern.com \
--cc=dana@dana.is \
--cc=sgniazdowski@gmail.com \
--cc=zsh-workers@zsh.org \
/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).