On 30 Nov 2009, at 14:10, 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.
Let me try to guess what your definition of portability is by assuming it means "will run in any POSIX shell". Firstly, if you are writing FOR the bash shell, you needn't worry about this type of portability. Putting bash in your hashbang means the script will only ever be interpreted by a bash shell, not any other POSIX shell. Secondly, if you do decide that for some reason you want to have your script interpretable by other POSIX shells (which means you avoid all other bash-specific features, too) your concern over portability still does not warrant the implementation being changed, as POSIX does not require shells to avoid subshelling components of a pipeline. So you still can't rely on other non-bash shells that are POSIX-compliant to treat your script's implementation the same. That said, the command substitution is an excellent alternative in any case for the pipeline-to-read problem. It is clean and has no side-effects. If your real issue is that many people struggle with this because they are newbies and haven't learned the intricacies of the shell yet, then surely this is not the first or biggest obstacle in that respect. Even (self-)proclaimed bash geniuses still fail at quoting expansions properly because they do not understand or appreciate the intricacies of word-splitting and pathname expansions.