On Mon, 30 Nov 2009, Marc Herbert wrote:
> Lhunath (Maarten B.) a ?crit :
> > On 30 Nov 2009, at 11:34, Marc Herbert wrote:
> >
> >> Eric Blake a ?crit :
> >>> This is E4 in the FAQ:
> >>> ftp://ftp.cwru.edu/pub/bash/FAQ
>
> > Instead of ''commands | read var''
> > Use ''read var < <(commands)''
> > I hardly see a need to change the existing implementation.
>
> As mentioned in the FAQ, ''read var < <(commands)'' is not portable.
>
> All alternatives in the FAQ (portable or not) are less readable than a
> simple pipe. They are all more verbose and introduce an extra level of
> nesting when you have only one "command". They all need to be read
> "backwards" with respect to the execution flow. If you want to keep your
> code readable, they practically all force you to define a function for
> "commands" as soon as you have more than a few commands.
>
> Every entry in an FAQ is by mere definition a problem that many people
> wast... spend time on.
>
> It is admittedly not a question of life or death but some other shells
> apparently have it so why not bash? Just asking.
Why should it be the last element of a pipeline that is executed in
the current shell and not the first?
Suppose that I have a group of commands that sets some variables
and outputs information to the screen, for example (this is much
oversimplified):
{
x=$(( $something * 2 ))
printf "%d\n" "$x"
}
Now, I want to modify the output. I pipe it through a formatting
command:
{
x=$(( $something * 2 ))
printf "%d\n" "$x"
} | tr 0-9 9-0
All of a sudden, x is not set (or set to the wrong value). So it
should be the *first* command, not the last, that is executed in
the calling shell.
--
Chris F.A. Johnson, webmaster <http://woodbine-gerrard.com>
===================================================================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
