I have encountered a strange behavior when using the read
command and unquoted here-string when they still used to be subject to word-splitting (in older versions of bash
). Please take a look at the following snippets:
Here echo $line
splits on IFS=:
and results in echo a b c
- OK:
IFS=:
line=a:b:c
echo $line | { read -ra arr; declare -p arr; }
Output:
declare -a arr='([0]="a b c")'
echo $line
results in echo a:b:c
as it doesn't contain any characters from default IFS
and read
then splits on IFS=:
and correctly populates the array - OK:
unset IFS
line=a:b:c
echo $line | { IFS=: read -ra arr; declare -p arr; }
Output:
declare -a arr='([0]="a" [1]="b" [2]="c")'
Question:
unset IFS
line=a:b:c
echo $line # outputs correctly a:b:c
IFS=: read -ra arr <<< $line
declare -p arr
Output:
a:b:c
declare -a arr='([0]="a b c")'
Here <<< $line
should result in <<< a:b:c
since $line
doesn't contain anything from IFS
. read
should then correctly populate the array using IFS=:
but the result is only one element, space delimited. Why is that?
I am using GNU bash, version 4.1.17(1)-release (sparc-sun-solaris2.11)
where here-strings used to be subject to word-splitting. Quoting solves the issue but I don't see how, in this particular case, word-splitting should mess things up since even the echo $line ...
example works just fine.
In GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
(where here-strings are no longer being split) both unquoted and quoted versions work correctly.