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)