eval

In the first form, the return value of
EXPR is parsed and executed as if it were a little Perl program. The value of the expression (which is itself determined within scalar context) is first parsed, and if there weren't any errors, executed in the context of the current Perl program, so that any variable settings or subroutine and format definitions remain afterwards. Note that the value is parsed every time the eval executes. If
EXPR is omitted, evaluates
$_. This form is typically used to delay parsing and subsequent execution of the text of
EXPR until run time.

In the second form, the code within the
BLOCK is parsed only once--at the same time the code surrounding the eval itself was parsed--and executed within the context of the current Perl program. This form is typically used to trap exceptions more efficiently than the first (see below), while also providing the benefit of checking the code within
BLOCK at compile time.

The final semicolon, if any, may be omitted from the value of
EXPR or within the
BLOCK.

In both forms, the value returned is the value of the last expression
evaluated inside the mini-program; a return statement may be also used,
just as with subroutines. The expression providing the return value is
evaluated in void, scalar, or list context, depending on the context of the
eval itself. See wantarray for more on how the evaluation context can be determined.

If there is a syntax error or runtime error, or a die() statement is executed, an undefined value is returned by eval(), and $@ is set to the error message. If there was no error, $@ is guaranteed to be a null string. Beware that using eval() neither silences perl from printing warnings to
STDERR, nor does it stuff the text of warning messages
into $@. To do either of those, you have to use the $SIG{__WARN__} facility. See
warn and the perlvar manpage.

Note that, because eval() traps otherwise-fatal errors, it is useful for determining whether a
particular feature (such as socket() or symlink()) is implemented. It is also Perl's exception trapping mechanism, where the
die operator is used to raise exceptions.

If the code to be executed doesn't vary, you may use the eval-BLOCK form to
trap run-time errors without incurring the penalty of recompiling each
time. The error, if any, is still returned in $@. Examples:

When using the eval{} form as an exception trap in libraries, you may wish not to trigger any __DIE__ hooks that user code may have installed. You can use the local $SIG{__DIE__} construct for this purpose, as shown in this example:

With an eval(), you should be especially careful to remember what's being looked at when:

eval $x; # CASE 1
eval "$x"; # CASE 2

eval '$x'; # CASE 3
eval { $x }; # CASE 4

eval "\$$x++"; # CASE 5
$$x++; # CASE 6

Cases 1 and 2 above behave identically: they run the code contained in the
variable $x. (Although case 2 has misleading double quotes making the reader wonder
what else might be happening (nothing is).) Cases 3 and 4 likewise behave
in the same way: they run the code '$x', which does nothing but return the value of $x. (Case 4 is preferred for purely visual reasons, but it also has the
advantage of compiling at compile-time instead of at run-time.) Case 5 is a
place where normally you WOULD like to use double quotes, except that in this particular situation, you
can just use symbolic references instead, as in case 6.