bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Syntax Question...


From: Greg Wooledge
Subject: Re: Syntax Question...
Date: Thu, 18 Aug 2011 09:37:47 -0400
User-agent: Mutt/1.4.2.3i

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)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]