Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Eli Schwartz <eschwartz@archlinux.org>
Newsgroups: gnu.bash.bug
Subject: Re: x[
Date: Mon, 29 Jul 2019 19:53:57 -0400
Lines: 98
Approved: bug-bash@gnu.org
Message-ID: <mailman.208.1564444448.1985.bug-bash@gnu.org>
References: <CAAZkfoK2hYq_qSkdKYc1on=+V4VEBgpgZW96sYNZwC+AMw7iTw@mail.gmail.com> <9EA25AF1-6D80-456A-81FA-6D908072E624@gmail.com> <a6a2b6a8-6151-78dc-41be-fc81250a40e5@archlinux.org> <db16f8b8-2a6d-a894-799d-f31827e72d92@inlv.org> <0aceaf50-5729-4ae2-c5be-a66a2ac6e6b8@archlinux.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LP9vlspLYXQwY4VLeOtJJx0B1KTARygNX"
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Openpgp: preference=signencrypt
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
In-Reply-To: <db16f8b8-2a6d-a894-799d-f31827e72d92@inlv.org>
Precedence: list
Xref: csiph.com gnu.bash.bug:15271

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--LP9vlspLYXQwY4VLeOtJJx0B1KTARygNX
Content-Type: multipart/mixed; boundary="kKjnbtdjTXuvzPB0PKPBqiP0hsjwkbq0x";
 protected-headers="v1"
From: Eli Schwartz <eschwartz@archlinux.org>
To: bug-bash@gnu.org
Message-ID: <0aceaf50-5729-4ae2-c5be-a66a2ac6e6b8@archlinux.org>
Subject: Re: x[
References: <CAAZkfoK2hYq_qSkdKYc1on=+V4VEBgpgZW96sYNZwC+AMw7iTw@mail.gmail.com>
 <9EA25AF1-6D80-456A-81FA-6D908072E624@gmail.com>
 <a6a2b6a8-6151-78dc-41be-fc81250a40e5@archlinux.org>
 <db16f8b8-2a6d-a894-799d-f31827e72d92@inlv.org>
In-Reply-To: <db16f8b8-2a6d-a894-799d-f31827e72d92@inlv.org>

--kKjnbtdjTXuvzPB0PKPBqiP0hsjwkbq0x
Content-Type: text/plain; charset=utf-8
Content-Language: en-US-large
Content-Transfer-Encoding: quoted-printable

On 7/29/19 6:01 PM, Martijn Dekker wrote:
> As others pointed out, it's the start of an array assignment, and
> associative array indexes can contain newlines.

Yeah, I think that was a bit of a retrospective lightbulb moment for a
bunch of people on #bash

> <(Process substitution) may look superficially like a fancy form of
> redirection[*], but it's actually more akin to command substitution: th=
e
> command inside is run, and the substitution is replaced, not with that
> command's output, but with a file name from which to read that command'=
s
> output (or, in the case of >(process substitution), a file name to whic=
h
> to write that command's input).
>=20
> Because that command is empty in this instance, bash does not bother to=

> substitute a file name, and the <() is substituted by nothing.
>=20
> So, let's get rid of the function (because it is a distraction) and jus=
t
> see how 'x=3Dfoo' is parsed in substitutions and redirections:

Yeah, that much is obvious. But the point I was trying to make was that
whatever the issue or misunderstanding was, it didn't seem to be as
simple an issue as "because glob expansion", because I would expect a
glob expansion to not care about where on the command line it gets expand=
ed.

Variable assignment, on the other hand, does make sense why it wouldn't
be going into effect after the parser started reading a command (even a
null element that does nothing at all). The fact that (array) variable
assignment was in play here is what we all missed. :p

--=20
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User


--kKjnbtdjTXuvzPB0PKPBqiP0hsjwkbq0x--

--LP9vlspLYXQwY4VLeOtJJx0B1KTARygNX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvSewel70XCra9w4EhIGKaBmvSpsFAl0/hxUACgkQhIGKaBmv
SpuJLhAAzYFpHb1UDNfix+dWazQW4WI9r5jsf3CSdrObxhMl96tgNxDq1XP6mK5R
Y2saqsTutHGy6m6s99JmfgK8mLDr1ig3KWc1nq60evpD6ECObzSlQaYR48v5p8Le
3fhDyxx7nO6i9y/PoiYqr0hcAdlerC5PTggxJtHu3fKNHVbB7+1aGTTBKlYCI09w
qTyXO3PuJufko76GnsQGFFD+DMC14UJ3IyDnAc3CZ6CeQ/Sd8+ClZ/xcCEb1g5Fl
gXkI0vLO8NlH3C1WAsA4k2pCo3qICv4ARxiTcR+Sg6MJalINW2oCihFNtIXKuo25
Cxd/a8fghkaJtvwSMCk6JEHR9rKO4bc4+NvTgGe5mBRNHxP5bjWPulyM7CmKIcwU
jqi76pVp1SWB7C3XHEKRxQCigC+jlKFfcm19LbAol9f9mhWW5cNJfugBQBvnj18U
1ZoGsjkkzEXRBH9wm+YHpxRv2UZdyiEkzG3aUz4XPNBMioYR89CTySXO2ZCfSszr
4xESM9tW8OGGzKw+vRuwQ1I979T8dR6BESFlfZD8i83207ZiH8QJ8n6LUsO2Nbe1
msLQUgDOj0OCcz80Wnu+HteKx+l0aaTT52BnYDv1vS76h8BlV+E9ZSQ+ULDKrlVt
rkvirM9zEr6EJ4+UER4q3C8VaMenVWUg+turT2vcETA1nuRfPtOJAjMEAQEKAB0W
IQRgQRMEwJ02YoNA7v/OsWfvtXIr1gUCXT+HFQAKCRDOsWfvtXIr1sSpD/0bhbru
Dy0hBld4l3+k7tn/o3uBA/gIRPl1L9ORlLFTOrvr7H24brVkzYvK/IVhivVog8aS
c5RILl+2Y2aj6Tn/7WB6eI046WcqAFl32W5JXkr3PTYCbY6mMSlti+DdymmDozVo
YQXLqcC5lumCuaMQuHKmkKZaT58x8jMEo0xPUGbg2j2kYIkLjpfPAwebVoXUqQZT
3NqJMMr9POMd9Igd+B7y16IukTTBW1pGiY6Ngtm8RC+biquHO5XkAj1sM6D19BzO
gmJLJjj40UyBuYJEDoijyTIAHWyZIdTZcGIC7hGvkL+Z4tU8rWm7xCdcgWe4qaZk
ijPLbCnqOodEIa0m+7U1NG28yjqeKbQPvlaSvxYc/OpMHtF0SVoiVO1JxL2EhthG
1yiEvxOC1r1MLtL8IHMxwlO4jdujlCfbsAFNtZ5Dme5DbCDgHhi6ATTBi4pkfUhy
Q9p81546rOn0v3gJS1wthdybc5y4fpqpBVJSluo2LrHI1EkZpsXkmgLJ/e1T1MtP
PdRF9Ukx03eB9STWF3KjJmog6Ki2w1XOd8q3P4wDqGxWmoQzxBcdC7LMKs1BjaQZ
OVB/U6WmwiYKM0FlQhQHKRQAvIaqvOmtpGJ2aDUQtVF3QcHD2EghW0FYuKlRuvvt
Dkql6MeI/9XPNMQKrmJdpymAUsqVbS4kus7SYg==
=Y9S3
-----END PGP SIGNATURE-----

--LP9vlspLYXQwY4VLeOtJJx0B1KTARygNX--