[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: x[

From: Eli Schwartz
Subject: Re: x[
Date: Mon, 29 Jul 2019 19:53:57 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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: the
> 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 which
> to write that command's input).
> Because that command is empty in this instance, bash does not bother to
> substitute a file name, and the <() is substituted by nothing.
> So, let's get rid of the function (because it is a distraction) and just
> see how 'x=foo' 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 expanded.

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

Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]