On Nov 22, 2013, at 10:04 AM, Pierre Gaston <pierre.gas...@gmail.com> wrote:
> > > > On Fri, Nov 22, 2013 at 4:22 PM, Clint Hepner <cl...@renesys.com> wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i386 > OS: darwin13.0.0 > Compiler: clang > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' > -DCONF_OSTYPE='darwin13.0.0' -DCONF_MACHTYPE='i386-apple-darwin13.0\ > .0' -DCONF_VENDOR='apple' > -DLOCALEDIR='/usr/local/Cellar/bash/4.2.45/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -DMA\ > COSX -I. -I. -I./include -I./lib -I./lib/intl > -I/private/tmp/bash-4vKN/bash-4.2/lib/intl -DSSH_SOURCE_BASHRC > uname output: Darwin patikoija.local 13.0.0 Darwin Kernel Version 13.0.0: Thu > Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/REL\ > EASE_X86_64 x86_64 > Machine Type: i386-apple-darwin13.0.0 > > 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 > > $var is split on : and the expansion results in "hello world" which doesn't > contains a :, so var1 gets "hello world" > but yeah, this is a bit of a grey zone > Looking at the change log at http://tiswww.case.edu/php/chet/bash/CHANGES, I noticed item (jj) in the changes to bash 4.1 alpha: jj. Fixed a bug that caused variable expansion in here documents to look in any temporary environment. And I can observe that between bash 3.2 and bash 4.1: bash-3.2 $ FOO=foo; FOO=bar cat <<< "$FOO" bar bash-4.1 $ FOO=foo; FOO=bar cat <<< "$FOO" foo However, why is the new value of IFS applied to the expansion of $var, instead of the current? Shouldn't read get the literal string "hello:world" from the here string? And if $var is split, why doesn't this expression work the same as $ read var1 var2 <<< hello world which is equivalent to $ read var1 var2 world <<< hello The following works as expected, which implies that the new value of IFS is being applied prematurely, but the quotes protect the colon from causing splitting and being removed until "hello:world" can be properly split inside the read builtin. $ IFS=: read var1 var2 <<< "$var"