[50 character or so descriptive subject here (for reference)]

[Steve Simmons]

Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.5.1
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DHOSTTYPE='sparc' 
-DOSTYPE='solaris2.5.1' -DMACHTYPE='sparc-sun-solaris2.5.1' -DSHELL 
-DHAVE_CONFIG_H -DSunOS5  -I. -I. -I./lib -g -O2
uname output: SunOS canary.aa.ans.net 5.5.1 Generic_103640-31 sun4u sparc 
SUNW,Ultra-1
Machine Type: sparc-sun-solaris2.5.1

Bash Version: 2.02
Patch Level: 1
Release Status: release

    Description:
            IFS in-line interpretation on command line inconsistant with
            other semi-POSIX shells

    Repeat-By:

    With bash:

        bash-2.02$ FOO="a:b:c" ; export FOO
        bash-2.02$ echo $FOO
        a:b:c
        bash-2.02$ IFS=":${IFS}" echo $FOO
        a:b:c
        bash-2.02$ IFS=":${IFS}" set $FOO
        bash-2.02$ echo $*
        a:b:c
        bash-2.02$ IFS=":${IFS}" ; export IFS
        bash-2.02$ echo $FOO
        a b c
        bash-2.02$ set $FOO
        bash-2.02$ echo $*
        a b c

    With sh (solaris 2.5.1, FreeBSD 4.5), ksh (solaris 2.5.1, I believe
    it's ksh 89), with ksh93 (FreeBSD 4.5, ksh93 package) the result is
    different in the third command:

        $ FOO="a:b:c" ; export FOO
        $ echo $FOO
        a:b:c
        $ IFS=":${IFS}" echo $FOO
        a:b:c
        $ IFS=":${IFS}" set $FOO
        $ echo $*
        a b c
        $ IFS=":${IFS}" ; export IFS
        $ echo $FOO
        a b c
        $ set $FOO
        $ echo $*
        a b c

    When run with --posix, bash-2.02 performs as do the other shells,
    ie, the third echo command produces 'a b c'.  However, I can find
    no documentation anywhere decribing standard bash behavior as
    varying from POSIX on this issue, and the bash documentation on
    the effect of changing IFS so similar to the documentation on other
    shells that it leads me to think this is unexpected.

    The casual observer might ask why this matters.  :-)  This behaviour
    was first noticed in while developing a system-wide set of initialization
    scripts and shell functions which (we hoped) would be usable for all
    bourne-ish shells.  We were surprised to find that this shell function
    works for ksh and sh but not bash:

      split_on_colons () {
          IFS=":${IFS}" set `echo $@`
          echo $@
      }

    In use, we have shell scripts and functions which do various iterations
    over colon-separated paths.  As a degenerate example:

        for P in `split_on_colons $PATH` ; do
            echo "Path contains: $P"
        done

    With split_on_colons defined as above, this works for all bournish shells
    except bash.

    Changing $@ to $* does not change the performance.

    bash 2.05 gives the same performance as the above bash; the bashbug
    header would be:

    Configuration Information [Automatically generated, do not change]:
    Machine: i386
    OS: freebsd4.4
    Compiler: cc
    Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
    -DCONF_OSTYPE='free
    bsd4.4' -DCONF_MACHTYPE='i386-unknown-freebsd4.4'
    -DCONF_VENDOR='unknown' -DSHELL  -DHAVE_CONFIG_H   -I.  -I. -I./include 
-I./lib -O -pipe
    uname output: FreeBSD superior.inland-sea.com 4.5-STABLE FreeBSD
    4.5-STABLE #4:
    Wed Apr 24 20:52:24 EDT 2002
    root@superior.inland-sea.com:/usr/src/sys/compile/SUPERIOR  i386
    Machine Type: i386-unknown-freebsd4.4

    Bash Version: 2.05a
    Patch Level: 0
    Release Status: release


Fix:
    None known, but we do have a different function which works for
    all of sh/ksh/bash:

    split_on_colons () {
        OLDIFS="${IFS}"
        IFS=":${IFS}"
        echo $@
        IFS="${OLDIFS}"
    }

    If current bash behaviour is considered to be correct then that's
    fine; it simply ought to be noted somewhere.  And my advance apologies
    if it already is and I just missed it.