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)
