no parameter expansion and no special meaning to control operator

[Lorenzo Viali]

Configuration Information [Automatically generated, do
not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-pc-linux-gnu-gcc
Compilation CFLAGS:  -DPROGRAM='bash'
-DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu'
-DCONF_MACHTYPE='i386-pc-linux-gnu' -DCONF_VENDOR='pc'
-DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib
  -Os -mcpu=i686 -pipe
uname output: Linux gseba-mobile 2.6.18-rc7 #3 Fri Sep
22 18:37:46 GMT 2006 i686 Mobile AMD Sempron(tm)
Processor 3300+ AuthenticAMD GNU/Linux
Machine Type: i386-pc-linux-gnu

Bash Version: 3.1
Patch Level: 17
Release Status: release

Description:
        my script has an option in which it receives
a command file's name and a pattern of arguments to
invoked the command with; at some stages of the
script,
the pattern is analyzed and a list of arguments for
the
command is created; now, to launch the command, I have
found that the following line is applicable:
        eval "\"$CMDFILE\" $list"
        because i need $CMDFILE to receive more than
one argument; but what happens is that if in the
script's option's arguments, there are substrings like
$i, those variable are expanded, if they exist, at the
moment of `eval'; also other commands can be launched,
through the control operators '&&', ';' etc.
        avoiding control operators seems to work with
the following line:
        ( eval exec "\"$CMDFILE\" $list" )
        but still, there takes place unwanted
parameter expansion;

Fix:
        so what I think of as a solution is either a
flag to the `set' builtin to disable parameter
expansion and one to ignore control operators, or a
flag to `eval' itself, with the same intention

Does this seem reasonable?
Thanks


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com