On Thu, Aug 27, 2009 at 06:13:38AM -0700, Arenstar wrote:
> temp="mysqldump -h $DBSource -u $USER -p$PASS $DB $TABLE --where='$Field
> > $VarStart AND $Field < $VarEnd' > $TABLE$DumpName"
> exec $temp
The obvious problem here is that you want the last ">" to be treated as
a redirection operator. This means the parser has to see it, outside
of a variable, and recognize it as a redirection, rather than a piece
of raw data. Either the > has to be put on the exec line outside of a
variable, or you to use eval. But if you use eval, it would change the
meaning of your inner quoted expression.
There is also a more subtle problem you've missed: the --where thing
contains whitespace, so it's going to be word-split in ways that you
simply can't deal with using this sort of approach.
Best bet if you have to retain the putting-commands-into-variables nonsense
is to split it into two parts: a command, which should be stored in an
array, rather than a string; and an output destination.
command=(mysqldump -h "$DBSource" ... --where="$Field > $VarStart...")
output=$TABLE$DumpName
exec "${comma...@]}" > "$output"
This accomplishes a few things:
1) The command can have all the quoted whitespace you want without any
danger. You just can't have any pipes, redirections, etc. in it.
2) The > is seen as a redirection, without problems.
3) You didn't have to use eval, and endure the headaches eval brings with it.
Now, personally, I'd just skip all the putting-commands-into-variables
nonsense and write it like this:
exec mysqldump -h "$DBSource" -u "$USER" -p"$PASS" "$DB" "$TABLE" \
--where="$Field $VarStart AND $Field < $VarEnd" \
> "$TABLE$DumpName"
I cover these issues in a bit more depth at:
http://mywiki.wooledge.org/BashFAQ/050
