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
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
