5.1 The String Form: Expression Evaluation

When Perl is given a file to execute or a string as a command line option (using -e), it needs to parse the contents, check it for syntax errors, and, if all is fine, execute it. Perl makes this feature available to the programmer through the eval string form. This contrasts powerfully with languages such as C, C++, or Java, where the compiler itself is a separate beast from your program, not available to it at run-time. In other words, the Perl interpreter itself works somewhat like this:

# Slurp in the entire file
while ($line = <>) {
    $str .= $line;   # Accumulate the entire file.
}

# $str now contains the entire file. Execute it !
eval $str;

As you can see, eval handles any Perl script handed to it. The beauty of this thing is that this facility is available not just to Larry, but to mortals like you and me. Try this:

# put some code inside $str
$str = '$c = $a + $b'; # Perl doesn't care what's inside $str
$a = 10; $b = 20;
eval $str;             # Treat $str as code, and execute it.
print $c;              # prints 30

In this snippet, $str is treated as an ordinary string at first, because that is what it is. But eval thinks of it as a program and executes it. The important point is that it doesn't think of it as a separate program, but as if it belonged right there in the original code instead of the eval statement, as shown in Figure 5.1.

Figure 5.1: eval compiles and executes the string in its own context

For this reason, the string that is given to eval can use variables and subroutines available to it at that point, including my and local variables, and optionally produce new ones in the same environment. In the preceding example, the string given to eval adds two initialized variables ($a and $b) and produces a new variable, $c.

If you have more than one statement inside the string (remember that the string can be as big a program as you want), eval evaluates all of them and returns the result of the last evaluation:

$str = '$a++; $a + $b'; # Contains two expressions
$a = 10; $b = 20;
$c = eval $str; # $c gets 31 (result of the 2nd expression, $a+$b)

Of course, it's quite pointless to eval a piece of code that you know at compile time, as in the example above. Things get interesting if $str comes from elsewhere - standard input, a file, or over the network. We will shortly look at some examples that make use of this.

NOTE: The string form of eval is a security risk. If the string argument comes from an untrusted source and contains, say,

system('rm *')

the code would be merrily executed - and result in a distinct lack of merriment on your part. In situations in which you cannot trust input, you can use the taint-checking option provided by Perl, which prevents you from using data derived from outside the program to affect files or things outside the program [5]. You can also use the Safe module bundled with the Perl distribution, which provides safe compartments in which to eval strings, similar to the environment that a web browser provides for Java or Tcl/Tk applets.

What if $str doesn't contain a valid Perl expression? Perl then puts an error message in a special variable called $@ (or $EVAL_ERROR, if you use the English module). Since eval compiles the string before actually executing it, this can be either a compilation or a run-time error. $@ is guaranteed to be undef if $str contains error-free code (well, I should say free of syntax errors, because it can't really protect you against flawed logic).

Since eval is used by the Perl interpreter itself to parse and execute a given script, the error strings (in $@) are exactly those you see on the standard error output when processing a flawed script.

There is one subtle, yet important, point that needs to be mentioned. eval treats the string as a block, which is why it is able to process a number of statements (not just expressions) and return the value of the last statement. This also means that you don't see the changes to localized or lexical variables present in the eval'ed string.