Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15271

Re: x[

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

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

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: x[ Eli Schwartz <eschwartz@archlinux.org> - 2019-07-29 19:53 -0400

csiph-web