On Tue, Oct 13, 2015 at 01:51:03PM -0700, Linda Walsh wrote: > Well, we have > "<< xxx" > as a HERE DOC using a tmp file
Correct. Note that xxx is just the sentinel to tell bash where the here document ends. It's not part of the data. > , Some time ago, the ability to do > "multiple assignments" at the same time was added (when I asked how to > do that) You are confused. Nothing was added. > that was told to use: > > "read x y z <<< "one two three" This is simply how the read commands works. If you give read three variable names, it will break the line into fields (assuming IFS is not empty) and assign the first field to the the first variable, the second field to the second variable, and THE ENTIRE REMAINING LINE (delimiters and all!) to the third variable. > (which I initially equated to something like: > (x y z)=(one two three) You are mixing things up. There are two different pieces of syntax here: the read command, and the here string syntax. The here string syntax <<< is exactly like a here document << except that the here string is a single word terminated by a newline (or by quoting) instead of by a specified delimiter. The following two pieces of code are exactly the same: read x y z <<< "an input string" read x y z << EOF an input string EOF Moreover, the following two pieces of code give the same resulting variable contents: read x y z <<< "a much longer input string" read x y z << EOF a much longer input string with some other lines after it EOF In both cases, z="longer input string". The extra lines in the second code piece are not used, because read stops reading at the first newline. > Then came along a way to do a process in background and end up > with being able to read & process its data in the main (foreground) > process w/this syntax: > > readarray -t foregnd < <(echo $'one\ntwo\nthree') This is process substitution. It's not like here documents/here strings which use a temp file and syntactic delimiters. It runs a command in the background and establishes a named pipe (or uses a /dev/fd/* entry, depending on the platform) to connect the background process to the foreground command. The <(...) construction is replaced by the name of the FIFO or the /dev/fd/* entry. So as far as the foreground command is concerned, it is simply an input redirection: readarray -t foregnd < something The "something" happens to be a magical pipe/fd thing, that's all. The key is that it's somewhere in the file system, which allows an input redirection to point to it. readarray doesn't know anything magical is happening. It just reads standard input.