Path: csiph.com!xmission!news.glorb.com!usenet.stanford.edu!not-for-mail
From: Oleg Popov <dev-random@mail.ru>
Newsgroups: gnu.bash.bug
Subject: Re: Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?
Date: Sun, 18 Oct 2015 05:27:12 +0300
Lines: 49
Approved: bug-bash@gnu.org
Message-ID: <mailman.533.1445135254.7904.bug-bash@gnu.org>
References: <56218DA5.8030501@tlinx.org> <5622CDC8.2030102@case.edu> <5622EB23.6020700@tlinx.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Content-Disposition: inline
In-Reply-To: <5622EB23.6020700@tlinx.org>
Precedence: list
Xref: csiph.com gnu.bash.bug:11689

On Sat, Oct 17, 2015 at 05:43:15PM -0700, Linda Walsh wrote:
> [cut]
> from a semantic point of view,  how is:
> 
>    readarray foo < <(cat /etc/passwd)
> 
> different from
> 
>    shopt -s lastpipe
>    cat /etc/passwd |readarray foo
> 
> Is there something in the semantics that would require they
> be implemented differently?
> [cut]

readarray < <(...) is not something "implemented" since it's not a 
single feature. It's a combination of two unrelated features ("<" and 
"<(...)") and unlikely an intended way to use <(...).

<(...) and >(...) let you insert stream producers and consumers (which 
are processes) into a command as filenames. Example:

    diff <(curl http://example.com) <(curl http://example.org)

diff expects you to pass it two *files*, not processes, and the process 
substitution feature lets you provide it with those files, even though 
they are actually pipes backed by processes.

Another example:

    curl http://example.com | \
	tee >(curl -T. ftp://host1/a) >(curl -T. ftp://host2/b)

tee duplicates its input and writes it into multiple files. It cannot 
start processes and works only with files, but in this example it sees 
two filenames (which are actually pipes to curl) and writes two copies 
of its input into them, essentially uploading the input to two ftp 
servers in parallel.

And your "readarray foo < <(...)" is just a hack you do on top of it.  
You tell bash to replace <(...) with a filename, and the command becomes 
something like "readarray foo < /dev/fd/5". It doesn't really care where 
it does the substitution: in arguments to diff or after "<".

Asking why bash inserts filename here is like asking why it runs "cat" 
when you type something like "foo | cat | cat | cat | bar" even though 
it's equivalent to "foo | bar". It does so because YOU told it to do so.