The read builtin in ash performs word splitting differently depending on whether the first character in $IFS is a space. printf 'a\t\tb\tc\n' | busybox ash -c 'IFS=$(printf "\t") read a b c; echo ".$a. .$b. .$c."' .a. .. .b c. printf 'a\t\tb\tc\n' | busybox ash -c 'IFS=$(printf " \t") read a b c; echo ".$a. .$b. .$c."' .a. .b. .c. printf 'a,,b,c\n' | busybox ash -c 'IFS="," read a b c; echo ".$a. .$b. .$c."' .a. .. .b,c. printf 'a,,b,c\n' | busybox ash -c 'IFS=" ," read a b c; echo ".$a. .$b. .$c."' .a. .b. .c. This isn't right. Whether multiple characters form a single field separator depends on whether those characters themselves are whitespace characters, not on whether space is present in $IFS. Current behaviour is different from how IFS is handled during ordinary word splitting, different from what susv3 specifies, and different from other shells, so I'm going to assume this is unintentional. For reference, here's bash's behaviour: printf 'a\t\tb\tc\n' | bash -c 'IFS=$(printf "\t") read a b c; echo ".$a. .$b. .$c."' .a. .b. .c. printf 'a\t\tb\tc\n' | bash -c 'IFS=$(printf " \t") read a b c; echo ".$a. .$b. .$c."' .a. .b. .c. printf 'a,,b,c\n' | bash -c 'IFS="," read a b c; echo ".$a. .$b. .$c."' .a. .. .b,c. printf 'a,,b,c\n' | bash -c 'IFS=" ," read a b c; echo ".$a. .$b. .$c."' .a. .. .b,c.
Thanks for reporting it here. Of interest to whoever decides to look at this bug. http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05 http://www.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_22_02_06_05
Created attachment 223 [details] Fix Try attached patch
Nice, I played with it a bit and it didn't break. It gives the results I expect.
same bug probably exists in hush ;)
hush's read simply doesn't do word splitting at all.
According to http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05 (provided I interpret it correctly) the following printf '\t,\ta\t,\tb\tc' | ash -c 'IFS=$(printf " \t,") read a b c d; echo ".$a. .$b. .$c. .$d."' should result in: .. .a. .b. .c. In version 1.15.3 it however results in: .a. .b. .c. .. The fix-patch from this ticket introduced the bug. Patch with fix and some test cases attached.
Created attachment 879 [details] Fix for the problem described in comment #6
Fixed in git, thanks!