Re: IFS handling and read

[Lhunath (Maarten B.)]

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.