Shell Programming and Scripting

thank you

If you don't understand why it works, then you've probably set yourself up for a surprise down the line when some kind of input you weren't expecting breaks it. eval is finicky that way. After all you're not feeding data into the shell, you're feeding it entire shell statements, and an unexpected backtick, pipe, semicolon, dollar sign, single quote, double quote, backslash will be interpreted by the shell as part of a statement and cause syntax errors or -- worse -- execute something unintended.

For this reason eval is to be avoided. It's difficult to safely control.

The answer to your question is simple enough. What, precisely, does it print when you run echo instead of eval?

Code:

echo echo "\" `cat myfile.file`\""

If it prints anything but a completely 100% syntactically-correct shell statement, then eval won't like it. If it's a valid shell statement, eval will run it. Nothing mysterious about it.

It's going to print something like

Code:

echo "line1
line2
line3
line4
line5
line6"

...which, as it happens, is a valid shell statement for printing those lines. Feed that into eval and it faithfully runs echo to print:

Code:

line1
line2
line3
line4
line5
line6

Correct me if I'm wrong, but that's not what you actually wanted, and why we've been shouting at you to ditch the useless echo.

If your file happens to contain a " character anywhere, this will be a huge problem for you, because eval will take it as an end-of-string which will cause a syntax error.

thank you

I have already explained repeatedly.

Step 1: Expand things like variables and backticks and backslashes, to turn echo "\" `cat myfile.file`\"" into

Code:

echo "line1
line2
line3
line4
line5"

Step 2: eval it, which runs the given shell statement.

thank you

Yes, exactly. It does the normal substitution step like any other shell command, then starts over.

You have shell variables in your sql file, even though it's not a shell script? Yeah, that's awkward.

One way to substitute would be to put it all into a here-document like this:

Code:

cat <<EOF
This will print everything up to an EOF at the beginning of the line
${variables} and `echo backticks` are substituted, but
commands are not.  You can \${escape} them to get the literal characters.
EOF

This takes the big SQL file, puts cat <<__EOF___ at the front of it, __EOF__ at the end of it, escapes ` and $( and \, prevents people from sneaking out of the here-document with their own __EOF__, and runs it in a shell. It will swallow the entire text nearly raw, substituting variables and nothing else. Results in /tmp/converted, or you can use them directly via a pipe.

Code:

echo "cat <<___EOF___" > /tmp/script
sed 's/\\/\\\\/g;s/`/\\`/g;s/^___EOF___/ ___EOF___/' /path/to/sql >> /tmp/script
echo "___EOF___" >> /tmp/script

/bin/sh /tmp/script > /tmp/converted
rm -f /tmp/script

This would be far less risky than eval -- less risk of malicious use, and less risk of accidental syntax errors due to embedded ' " | ` ( ) &

And, of course, if Ratna would take the echo commands out of the file named by $file_var, she could just use:

Code:

. "$file_var"

and get the same results without having to worry about command substitution and quote removal happening twice. I just don't know why we can't convince her that sourcing a file runs the commands in that file with all of the attendant command substitution, variable expansions, and quote removal that would happen if the commands in that file were located in the calling shell script. Oh, well.