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
