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
# Case (2) Expected behavior, consistent with case (3)
$ IFS=: read var1 var2 <<< "$var"
$ echo "$var1"
hello
# Case (3) - no parameter expansion involved with the read
$ IFS=: read var1 var2 <<< hello:world
$ echo "$var1"
hello
# Case (4) - an explicit here document instead of a here string
$ IFS=: read var1 var2 <<EOF
> $var
> EOF
$ echo "$var1"
hello
