print __LINE__, "\n";
print __LINE__, "\n";
eval {print __LINE__, "\n";};
__OUTPUT__
6
7
8
[download]

The preceeding code prints three sequential numbers. I bring this up because it could be guessed (or hoped) that __LINE__ might be relative to the top of the code being processed in the eval block. In fact, it is not, if it uses eval's {block} syntax.

However, __LINE__ will return a different result if you wrap the eval'ed code in quotes. See the following code:

print __LINE__, "\n";
print __LINE__, "\n";
eval "print __LINE__,qq/\n/;
      print __LINE__,qq/\n/;
      die()";
print $@, "\n";
print __LINE__, "\n";

__OUTPUT__
6
7
1
3
Died at (eval 1) line 5.

12
[download]

As you can see, that code prints the 6 and 7 as absolute file linenumbers. But the 1 and 3 are loosely relative to the quoted eval material. The "line 5" generated by trapping the die shows the odd behavior that in the case of lines of code eval'ed within quotes line numbers seem to skip a number for each line. Finally, the printing of '12' indicates that once back outside the eval function, the original numbering scheme resumes, unaffected by eval's apparent reset of __LINE__. So line must be localized within quoted eval strings.

I'd be interested in seeing any documentation for this behavior.