Shell Programming and Scripting

But why are you using it? What function does it perform that tar by itself couldn't? You don't even need eval to expand wildcards, the shell does that when evaluating any unquoted variable.

Try $mycommand without the eval.

The problem I encountered was that wildcards *were* expanded when I didn't want them to be. If exclude="C *.txt" then "for i in ${exclude}" expands the asterisk in *.txt to a list of .txt files in the current directory, rather than passing the string "*.txt" to tar. I couldn't see an easy way around it, hence the eval. Happy now or still hate it?

As it is "eval" won't help you avoid this problem, but in fact make it worse. Without "eval" your command line becomes interpreted by the shell once, with it twice. I don't think "eval" should be avoided generally (like you seem to believe Corona688 is thinking), but in this case it is simply the wrong tool - and probably very dangerous, as Corona688 pointed out correctly.

If you want to avoid interpretation of a certain string use quotation - that is, what it is for. For intance:

Code:

exclude="*.txt"

$ echo $exclude
a.txt b.txt c.txt
$ echo "$exclude"
*.txt
$ echo '$exclude'
$exclude

Now, let us apply this to your problem. I use ":" as a delimiter here, like in the PATH variable, because commas or something such could be used in filenames and i want to avoid that:

Code:

#! /bin/ksh

excludelist="foo:*.bar:baz.*"

exclude=""

while [ -n "$excludelist" ] ; do
     exclude="$exclude --exclude \"${excludelist%%:*}\""
     if [ "${excludelist%%:*}" = "${excludelist}" ] ; then
          excludelist=""
     else
          excludelist="${excludelist#*:}"
     fi
     # this is just to show how it works, can be removed:
     print - "excludelist: \"$excludelist\" args to tar: \"$exclude\""
done

tar <options> $exclude <more options>

I would like to say for the record, that i don't think the contents of the variable excludelist should be modified by modifying the scripts text at all. Instead a configuration file should be passed to the script, which contains all the exclusions. How to construct a syntax for such a configuration file and how to parse it i have described here, but the way of feeding the options to tar will still be as lain out here.

I hope this helps.

bakunin

After giving the problem some afterthought, i think to know how the "eval" came to pass:

If you want to use wildcards with a special meaning and pass these to a utility without having them interpreted by the shell you have to use quotation:

Code:

opt="*"
utility $opt     # won't work unexpanded
utility "$opt"   # will work without expansion by shell

If you try to bind together several options into a single variable and put this variable into a quotation it will count as a single parameter:

Code:

opt="-a * -b ??"
utility $opt     # will become expanded, therefore useless
utility "$opt"  # will not become expanded, but will count as only *one* option

There is a typical gotcha, which i found in some IBM software not too long ago: mysteriously the IBM utility made run "/dev" out of diskspace, which is a very bad idea under AIX. How did that come? Easy: first there was some line like:

Code:

tgt="/dev/null"
something > "$tgt"

But "something" also produced output on stderr and someone - very economically - changed "$tgt" therefore:

Code:

tgt="/dev/null 2>&1"
something > "$tgt"

This will not work any more, because now the output goes to a file named "null 2>&1", which is a regular file in "/dev" - of course, it will eventually run out of space.

If you now use "eval", this will restart the evaluation process and hence make the argument count correct again. Alas, this also restarts the evaluation process by the shell again and therefore wildcards will be expanded again too.

The only solution is to create your own option line in an evaluation-proof way like i have done in my script sketch: i surround the delicate wildcards with quotation of my own to protect them when i send the commandline unquotedly to the shell (see the "\"", which will create literal quotation marks in the output).

I hope this helps.

bakunin

You're using eval to avoid expansion? That's the oddest thing I've heard this week.

It's not that I "hate it". It's that it's "such a bad idea that you're going to kick yourself for it when something bad happens".

I believe tar has a --excludefile option or something like it which would be a much more elegant solution without putting self-modifying code into eval and hoping nothing bad happens.

It does.

From post #1:
Regards,
Alister