Word-splitting limitation with shell variables

[Mike Paul]

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-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H  -D_FILE_OFFSET_BITS=64  -I. 
-I/usr/include -I/home/swt/doko/export/packages/bash/bash-2.05 
-I/home/swt/doko/export/packages/bash/bash-2.05/include 
-I/home/swt/doko/export/packages/bash/bash-2.05/lib -I/usr/include -g -O2
uname output: Linux schala 2.4.2 #7 Sun Mar 4 10:51:28 EST 2001 i686 unknown
Machine Type: i386-pc-linux-gnu

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

Description:
        When evaluating the contents of a shell variable as a command string,
        there doesn't seem to be any way to cause multiple groups of
        space-separated characters to be treated as a single word, as can be
        done in an interactive shell by surrounding them with quotes.
        Evaluating a variable whose value _contains_ quotes ought to produce
        this behavior, I would think, but it doesn't.

Repeat-By:
        In an interactive shell:
        foo "filename containing spaces"
          passes "foo" in argv[0], "filename containing spaces" in argv[1]
          (correct behavior)

        In a script:
        cmd="foo \"filename containing spaces\"" ; ${cmd}
          passes "foo" in argv[0], "\"filename" in argv[1],
          "containing" in argv[2], and "spaces\"" in argv[3]
          (incorrect behavior)
        cmd="foo \"filename containing spaces\"" ; bash -c "${cmd}"
          works as in the interactive shell
          (correct behavior)