perl-5.20.1
eval EXPR
eval BLOCK
eval

In the first form, often referred to as a "string eval", 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 were no errors, executed as a block within the lexical context of the current Perl program. This means, that in particular, any outer lexical variables are visible to it, and any package variable settings or subroutine and format definitions remain afterwards.

第一の形式(しばしば「文字列 eval」として参照されます)では、EXPR の返り値が Perl のプログラムであるかのように解析され、実行されます。 式の値(それ自身スカラコンテキストの中で決定されます)はまずパースされ、 エラーがなければ Perl プログラムのレキシカルコンテキストの中のブロックとして 実行されます。 これは、特に、外側のレキシカル変数は見えていて、パッケージ変数の設定や サブルーチンやフォーマットの定義はその後も残っているということです。

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.

返される値は eval が実行されるごとにパースされることに注意してください。 EXPR が省略されると、$_ を評価します。 この形は主に EXPR のテキストのパースと実行を実行時にまで 遅延させるのに用います。

If the unicode_eval feature is enabled (which is the default under a use 5.16 or higher declaration), EXPR or $_ is treated as a string of characters, so use utf8 declarations have no effect, and source filters are forbidden. In the absence of the unicode_eval feature, the string will sometimes be treated as characters and sometimes as bytes, depending on the internal encoding, and source filters activated within the eval exhibit the erratic, but historical, behaviour of affecting some outer file scope that is still compiling. See also the evalbytes keyword, which always treats its input as a byte stream and works properly with source filters, and the feature pragma.

unicode_eval 機能が有効の場合(これは use 5.16 またはそれ以上が 宣言されている場合はデフォルトです)、EXPR や $_ は文字単位の文字列として 扱われるので、use utf8 宣言は無効で、ソースフィルタは禁止されます。 unicode_eval 機能がなければ、文字列は内部エンコーディングに依存して 時々文字単位として扱われ、時々バイト単位で扱われます; そして eval の 中で有効になったソースフィルタは、まだコンパイル中である一部の外側のファイル スコープに影響を与えるという、間違っているけれども歴史的な振る舞いを 見せます。 入力を常にバイト列として扱い、ソースフィルタが適切に動作する evalbytes キーワードおよび feature プラグマを参照してください。

Problems can arise if the string expands a scalar containing a floating point number. That scalar can expand to letters, such as "NaN" or "Infinity"; or, within the scope of a use locale, the decimal point character may be something other than a dot (such as a comma). None of these are likely to parse as you are likely expecting.

文字列をが小数点を含むスカラを展開するときに問題が起こることがあります。 そのようなスカラは "NaN""Infinity" のような文字に 展開されることがあります; または、use locale のスコープの中では、 小数点文字は (カンマのような) ドット以外の文字かもしれません。 これらはどれもあなたがおそらく予測しているようにはパースされません。

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.

第二の形式では、BLOCK 内部のコードは一度だけパースされ -- コードを 囲む eval 自身がパースされるのと同じ時点です -- 現在の Perl プログラムの コンテキストで実行されます。 この形式は典型的には第一の形式より効率的に例外をトラップします(後述); また BLOCK 内部のコードはコンパイル時にチェックされるという利点を提供します。

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

最後のセミコロンは、もしあれば、EXPR の値や 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.

どちらの形式でも、返される値はミニプログラムの内部で最後に評価された 表現の値です; サブルーチンと同様、return 文も使えます。 返り値として提供される表現は、eval 自身のコンテキストに依存して 無効・スカラ・リストのいずれかのコンテキストで評価されます。 評価コンテキストの決定方法についての詳細は wantarray を参照してください。

If there is a syntax error or runtime error, or a die statement is executed, eval returns undef in scalar context or an empty list in list context, and $@ is set to the error message. (Prior to 5.16, a bug caused undef to be returned in list context for syntax errors, but not for runtime errors.) If there was no error, $@ is set to the empty string. A control flow operator like last or goto can bypass the setting of $@. 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, or turn off warnings inside the BLOCK or EXPR using no warnings 'all'. See warn, perlvar, and warnings.

構文エラーや実行エラーが発生するか、die 文が実行されると、 eval はスカラコンテキストでは undef が、リストコンテキストでは 空リスト が設定されます。 (5.16 以前では、バグによって、リストコンテキストで構文エラーの時には undef を返していましたが、実行エラーの時には返していませんでした。) エラーがなければ、$@ は空文字列に設定されます。 lastgoto のようなフロー制御演算子は $@ の設定を回避できます。 eval を、STDERR に警告メッセージを表示させない目的や、 警告メッセージを $@ に格納する目的では使わないでください。 そのような用途では、$SIG{__WARN__} 機能を使うか、 no warnings 'all' を使って BLOCK か EXPR の内部での警告を オフにする必要があります。 warn, perlvar, warnings, warnings を参照してください。

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.

eval は、致命的エラーとなるようなものをトラップすることができるので、 (socketsymlink といった) 特定の機能が実装されているかを、 調べるために使うことができることに注意してください。 die 演算子が例外を発生させるものとすれば、これはまた、Perl の例外捕捉機能と 捉えることもできます。

If you want to trap errors when loading an XS module, some problems with the binary interface (such as Perl version skew) may be fatal even with eval unless $ENV{PERL_DL_NONLAZY} is set. See perlrun.

XS モジュールのロード中のエラーをトラップしたいなら、 (Perl バージョンの違いのような) バイナリインターフェースに関する問題に ついては $ENV{PERL_DL_NONLAZY} がセットされていない eval でも 致命的エラーになるかもしれません。 perlrun を参照してください。

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:

実行するコードが変わらないのであれば、毎回多量の再コンパイルすることなしに、 実行時エラーのトラップを行なうために、 eval-BLOCK 形式を使うことができます。 エラーがあれば、やはり $@ に返されます。 例:

    # make divide-by-zero nonfatal
    eval { $answer = $a / $b; }; warn $@ if $@;

    # same thing, but less efficient
    eval '$answer = $a / $b'; warn $@ if $@;

    # a compile-time error
    eval { $answer = }; # WRONG

    # a run-time error
    eval '$answer =';   # sets $@

Using the eval{} form as an exception trap in libraries does have some issues. Due to the current arguably broken state of __DIE__ hooks, 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 this example shows:

eval{} 形式をライブラリの例外を捕捉するために使うときには 問題があります。 現在の __DIE__ フックの状態はほぼ確実に壊れているという理由で、 ユーザーのコードが設定した __DIE__ フックを実行したくないかもしれません。 この目的には以下の例のように、local $SIG{__DIE__} 構造が使えます。

    # a private exception trap for divide-by-zero
    eval { local $SIG{'__DIE__'}; $answer = $a / $b; };
    warn $@ if $@;

This is especially significant, given that __DIE__ hooks can call die again, which has the effect of changing their error messages:

これは特に顕著です; 与えられた __DIE__ フックは die をもう一度 呼び出すことができ、これによってエラーメッセージを変える効果があります:

    # __DIE__ hooks may modify error messages
    {
       local $SIG{'__DIE__'} =
              sub { (my $x = $_[0]) =~ s/foo/bar/g; die $x };
       eval { die "foo lives here" };
       print $@ if $@;                # prints "bar lives here"
    }

Because this promotes action at a distance, this counterintuitive behavior may be fixed in a future release.

これは距離の離れた行動であるため、この直感的でない振る舞いは 将来のリリースでは修正されるかもしれません。

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

eval では、以下のような場合に、 何が調べられるかに特に注意しておくことが必要です:

    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.

上記の CASE 1 と CASE 2 の動作は同一で、変数 $x 内の コードを実行します。 (ただし、CASE 2 では、必要のないダブルクォートによって、 読む人が何が起こるか混乱することでしょう (何も起こりませんが)。) 同様に CASE 3 と CASE 4 の動作も等しく、$x の値を返す以外に 何もしない $x というコードを実行します (純粋に見た目の問題で、CASE 4 が好まれますが、 実行時でなくコンパイル時にコンパイルされるという利点もあります)。 CASE 5 の場合は、通常ダブルクォートを使用します。 この状況を除けば、CASE 6 のように、単に シンボリックリファレンスを使えば良いでしょう。

Before Perl 5.14, the assignment to $@ occurred before restoration of localized variables, which means that for your code to run on older versions, a temporary is required if you want to mask some but not all errors:

Perl 5.14 より前では、$@ への代入はローカル化された変数の復帰の前に 起きるので、古いバージョンで実行される場合は、全てではなく一部だけの エラーをマスクしたい場合には一時変数が必要です:

    # alter $@ on nefarious repugnancy only
    {
       my $e;
       {
         local $@; # protect existing $@
         eval { test_repugnancy() };
         # $@ =~ /nefarious/ and die $@; # Perl 5.14 and higher only
         $@ =~ /nefarious/ and $e = $@;
       }
       die $e if defined $e
    }

eval BLOCK does not count as a loop, so the loop control statements next, last, or redo cannot be used to leave or restart the block.

eval BLOCK はループとして 扱われません; 従って、next, last, redo といったループ制御文でブロックから離れたり再実行したりはできません。

An eval '' executed within a subroutine defined in the DB package doesn't see the usual surrounding lexical scope, but rather the scope of the first non-DB piece of code that called it. You don't normally need to worry about this unless you are writing a Perl debugger.

DB パッケージで定義されたサブルーチン内で eval '' を実行すると、通常の レキシカルスコープではなく、これを呼び出した最初の非 DB コード片の スコープになります。 Perl デバッガを書いているのでない限り、普通はこれについて心配する必要は ありません。