Re: read with parameter expansion in here string

[Pierre Gaston]

On Fri, Nov 22, 2013 at 4:22 PM, Clint Hepner <clint@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