On 11/22/13, 9:22 AM, Clint Hepner wrote:
> Bash Version: 4.2
> Patch Level: 45
> Release Status: release
>
> Description:
>
> An unquoted parameter expansion in a here string does not seem to
> conform with my understanding of how
> read works with a local IFS override. Personally observed in bash
> 3.2.51, 4.1.2 as well. I first learned
> of this possible bug via http://stackoverflow.com/q/20144593/1126841.
>
> Repeat-By:
> $ var="hello:world"
>
> # Case (1) I would expect "hello:world" in var1 if $var isn't split,
> or "hello"
> # if it is. World splitting seems to occur after var1 is set, which
> doesn't
> # seem to make sense.
> $ IFS=: read var1 var2 <<< $var
> $ echo "$var1"
> hello world
The read builtin gets "hello:world" as input; $var is not split using the
value of IFS passed to `read'. You can see this by using something like
IFS=: cat <<< $var
The idea is that read acts as it usually does: it reads a line of input
(hello:world), splits it into words on $IFS (:), resulting in multiple
words (hello world), and assigns the words to each variable in turn,
leaving $var1 as `hello'.
There is a bug in bash-4.2 involving cached values of $IFS that causes
your case (1) to not work right. It was fixed in January, 2013 and will
be in bash-4.3. If you want to look at the devel branch changelogs, there
is a more complete explanation.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
