On Thu, Aug 18, 2011 at 06:02:14AM -0700, Linda Walsh wrote: > The "shopt -s expand_aliases" feature has been in bash since I first > encountered it in ~1999.
Fine. You know more bash bad practices than I do. You win. > > b="one two three" > > read a <<<$b > > echo $a > one two three > The word following the redirection operator in the following descrip- > tions, unless otherwise noted, is subjected to brace expansion, tilde > expansion, parameter expansion, command substitution, arithmetic expan??? > sion, quote removal, pathname expansion, and word splitting. If it > expands to more than one word, bash reports an error. > > It seems to leave off variable expansion. I don't understand this... either it should be reporting an error, or it should *not* be expanding the variable. It doesn't seem to report an error on multiple-file pathname expansions either: imadev:~$ read a <<< *.pdf imadev:~$ echo "$a" *.pdf In fact, it's not even performing the expansion, as far as I can tell. And yes, I have pathname expansion enabled (set +f) and I have several *.pdf files in this directory. imadev:~$ cat <*.pdf bash: *.pdf: ambiguous redirect > > However, if your input source is a command rather than a variable > > expansion, then you should probably be using < <() instead: > > > > read progdir prog path export_blob < <(env_init "$progdir" "$prog" > "$this") > --- > Why? Seems like a different way to do it, but why do you prefer it? When you use <<< "$(...)" three undesirable things happen. The first is that the entire command is executed all at once, and the script has to wait for the entire process to finish. The second is that all the output is read into memory and stored, all at once. The third is that the stream is subtly altered: all trailing newlines are stripped by the $(...) and then one newline is added by the <<<. < <(...) by contrast runs the command in the background and reads from it piecemeal. So you get the stream's output as it's ready, a line at a time, and unaltered. It's probably not an important distinction in this particular example, since your command only appears to produce one line of output anyway, but in a loop it's a clear winner: while read ...; do ... done < <(some very long process)
