Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linu
x-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/
local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./incl
ude -I./lib -g -Wno-parentheses -Wno-format-security -fno-inline
uname output: Linux gomez 2.6.33.4-smp #2 SMP Wed May 12 22:47:36 CDT 2010 i686
Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.4
Patch Level: 12
Release Status: release
Description:
Here strings are documented as:
[n]<<<word
The word undergoes brace expansion, tilde expansion, parameter and
variable expansion, command substitution, arithmetic expansion, and
quote removal.
But brace expansion is not applied:
$ read zz <<< {1..9}
$ echo $zz
{1..9}
The codepath from write_here_string() does not pass through any
expand_xxx functions which apply brace expansion, AFAICT.
(bash was built with -fno-inline for gdb only)
Repeat-By:
$ read zz <<< {1..9}
$ echo $zz
{1..9}
Expected behaviour would be similar to:
$ read zz <<< $(echo {1..9})
$ echo $zz
1 2 3 4 5 6 7 8 9
Fix:
I have hacked a call to brace_expand() into write_here_string()
before it calls expand_string_unsplit_to_string() as a possible
solution, though I suspect there's a cleaner way... perhaps an
alternate expand_ function is available?
(I can clean this up and submit it if I'm barking up the right tree.)
