[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: read with parameter expansion in here string
From:       Chet Ramey <chet.ramey () case ! edu>
Date:       2013-11-23 2:25:25
Message-ID: 52901215.1030601 () case ! edu
[Download RAW message or body]

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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/


[prev in list] [next in list] [prev in thread] [next in thread]