unexpected behavior of 'read' builtin

[Juliano F. Ravasi]

Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic 
-fasynchronous-unwind-tables
uname output: Linux misuzu.aurora.juliano.info 2.6.24.7-92.fc8 #1 SMP 
Wed May 7 16:50:09 EDT 2008 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu

Bash Version: 3.2
Patch Level: 33
Release Status: release

Description:

        I got bitten by two unexpected (and undocumented) behaviors of
        the 'read' builtin.

        The first one is that it doesn't seem to handle word separators
        equally, making distinction when spaces and non-space
        separators are used to separate words.

        The second one is that it chops leading and trailing whitespace
        when you provide one variable for assignment, and not when you
        use the default $REPLY.

        I don't know if these are intended behavior, but it doesn't seem
        to be documented, leading to a surprise when you expect
        something and get some other thing instead.

Repeat-By:

        About word separators:

        ~$ IFS=':' read -a a <<< '1:2:3::5'; declare -p a
        declare -a a='([0]="1" [1]="2" [2]="3" [3]="" [4]="5")'

        ~$ IFS=$'\t' read -a a <<< $'1\t2\t3\t\t5'; declare -p a
        declare -a a='([0]="1" [1]="2" [2]="3" [3]="5")'

        Note how the fourth (blank) field is lost if a tab character is
        used as word separator, but not if ':' is used instead.

        About trailing and leading whitespace:

        ~$ read <<< '  a   b  '; declare -p REPLY
        declare -- REPLY="  a   b  "

        ~$ read VAR <<< '  a   b  '; declare -p VAR
        declare -- VAR="a   b"

        Note how whitespace is removed when using $VAR, but not when
        using $REPLY.

Fix:

        Either make 'read' consistent, or update the documentation to
        explain that there are these "corner cases", and why they exist
        (standards compliance, design decisions, whatever), so that
        users don't get surprised by them.

--
Juliano F. Ravasi ·· http://juliano.info/
5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96

"A candle loses nothing by lighting another candle."
    -- Erin Majors