eval qq/my \$v\xE9/;
eval q/print $string; $string = "new value"/;
print $@ if $@;
[download]

"my" variable $string masks earlier declaration in same scope at (eval 2) line 1.

Somehow $string is being declared lexical in the second eval. The specific error being triggered in the first eval (Unrecognized character \xE9) has a special case in toke.c, and I can only think this early exit is leaving the tokenizer in an odd state.

You should report this bug using the perlbug program you should have installed on your system. If you wish to include the details I've mentioned please feel free.

Thanks monks for your responses... i report a perl bug soon...

i have reported a perl bug (47517)

use strict;
use warnings;

my $var_with_é_accent;
[download]

Unrecognized character \xE9 at line 4.

WinXP SP2, ActivePerl 5.8.8 (build 817).

I guess you could argue that the error "breaks" the parser, and that it shouldn't really propagate outside of an eval.

Do the Perl docs actually say you can have non-ascii variable names?

-David

All of this is on 5.8.3, ActiveState build 809

Yes, the bug is that an error within eval should not affect other evals. I'm not sure where the problem lies, because the following code still works as expected and raises no error, no matter whether $string is a global or a lexical variable:

use strict;
use Test::More tests => 12;

sub second_eval_unaffected($) {
    my ($code) = @_;
    eval $code;
    diag $@ if $@;
    my $string = '';
    ok eval(q($string="new eval done";)), "Eval after >>$code<< still 
+works";
    is $@, '', "... and raises no error either.";
    is $string, 'new eval done', "... and sets the variable correctly"
+;
};

second_eval_unaffected 'my $var_without_accent;';
second_eval_unaffected 'my $var_with = "é_accent";';
second_eval_unaffected 'my statement_with_error;';
second_eval_unaffected 'my $var_with_é_accent";';
[download]

This program exhibits the problem as a self-contained Test::More program. The first sequence of steps leads to a failure, while the second run succeeds. This should not happen, but I don't know why :)

use strict;
use Test::More tests => 10;

sub gauntlet {
    my $code1=shift;

    my $string;
    my $expected = "new eval done";
    my $code2='$string="new eval done";';

    ok eval($code2), "Good code evals correctly";
    is $@, '', "... and raises no error on its own.";

    diag "Eval trial code\n";
    diag $code1;
    eval $code1; 
    diag '$@ is ', $@;

    undef $string;
    diag "Eval good code ($code2)\n";
    ok eval $code2;
    is $@, '', "No error raised";
    is $string, $expected;
};

gauntlet('my $var_with_é_accent;');
gauntlet('my $var_without_accent;');
[download]

The error is properly caught by the first eval. That's not the problem. The problem is that the error causes subsequent evals to work incorrectly (silently unable to access lexicals, at least).

i have made a new post with renders element...

in fact we eval code feeded by user ... i know that variables are ascii in perl but my users don't ... and ours application need to do more eval after evaluating buggy code of user...

Evaling user code is dangerous. If you can use a hash instead, you bypass the naming problem.