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.
