Re: IFS handling and read

[Chris F.A. Johnson]

On Mon, 30 Nov 2009, Lhunath (Maarten B.) wrote:

> On 30 Nov 2009, at 15:56, Chris F.A. Johnson wrote:
> > 
> > On Mon, 30 Nov 2009, Greg Wooledge wrote:
> > 
> >> On Mon, Nov 30, 2009 at 11:46:03AM +0100, Lhunath (Maarten B.) wrote:
> >>> Don't use pipelines to send streams to read.  Use file redirection 
> >>> instead:
> >>> 
> >>> Instead of ''command | read var''
> >>> Use ''read var < <(command)''
> >>> 
> >>> I hardly see a need to change the existing implementation.
> >> 
> >> Or for the original problem case, use a here string:
> >> 
> >> IFS=: read a b <<< "1:2"
> >> 
> >> Between process substitutions (the <(command) thing) and here strings,
> >> you should be able to do all your reads without subshells.
> > 
> >   Or, to be portable, use a here document:
> > 
> > IFS=: read a b <<.
> > 1:2
> > .
> > 
> >   This works with the output of commands, too:
> > 
> > IFS=- read year month day <<.
> > $(date +%Y-%m-%d)
> > .
> 
> Note that 'read' is a bash feature; not a POSIX shell feature.

    ?????

    The read command has been around since the early Bourne shells.

>  In that sense, "read" alone is limiting your "portability". So
> portability in the meaning of POSIX is out of the question.

> Perhaps you're talking about backward compatibility instead of
> portability, in which case the only compatibility gain you get from
> using the more verbose heredoc over the herestring is compatibiltiy
> with pre-2.05b-alpha1 bash.

> Hardly worth it.
> 

-- 
   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)