in reply to RE: RE: RE: RE: Re: How to tell eval where the code is from
in thread How to tell eval where the code is from

perlsyn (yeah, the one nobody reads {grin}) says:
Plain Old Comments (Not!) Much like the C preprocessor, Perl can process line directives. Using this, one can control Perl's idea of filenames and line numbers in error or warning messages (especially for strings that are processed with eval()). The syntax for this mechanism is the same as for most C preprocessors: it matches the regular expression /^#\s*line\s+(\d+)\s*(?:\s"([^"]*)")?/ with $1 being the line number for the next line, and $2 being the optional filename (specified within quotes). Here are some examples that you should be able to type into your command shell:
and goes on to give some examples.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
RE: RE: RE: RE: RE: RE: Re: How to tell eval where the code is from
by tilly (Archbishop) on Aug 08, 2000 at 18:03 UTC
    I actually did read perlsyn. I even go back and browse it periodically for fun. I have even written code that had no purpose other than to play with features that I found there. (For instance a program that was designed as a finite state machine, switching states with "goto &foo;".) I sincerely missed this particular point. Actually I remember seeing it, and not seeing why it would be useful, then forgetting it again.

    That said, unless I am missing something obvious, I find the above feature to be buggy for perl 5.005_03 on both Windows and Linux. Here is my test:

    $ perl $str = <<FOO; # line 1 "foo" sub bar { die('gotcha'); } &bar(); FOO print "When executed by eval:\n"; eval($str); print $@; print "When executed by perl:\n"; open (PERL, "| perl") or die "Cannot start perl: $!"; print PERL $str; close PERL; __END__ When executed by eval: gotcha at (eval 1) line 3. When executed by perl: gotcha at foo line 2.
    When I go home tonight I will try this on 5.6 and send a bug report in if I still cannot get it to work.

    For the record, I consider myself a Perl hacker, not a perl hacker. (VBG)

      Well it failed in 5.6, so I sent the bug report in and got a reply. Apparently it is a known bug, a CPP comment will fail in an eval if it is on the first line, so you just have to make your first line blank. merlyn had simply forgotten about that bug.

      OK, with that amusing gotcha out of the way, I think that this is incredibly nice to have. Until it was forcibly pointed out to me what you would want to use it for I didn't see the point, but now I do and I will use it. :-)

      On a side-note, I complained to merlyn that I remembered the days when I never saw bugs in Perl. Then I found out about some, but never worried about it much. Then I started hitting them myself. He tells me that he has never been bitten by a Perl bug. He knows about them, but has never been hit.

      I suspect our definitions may differ though... Here is my guess as to merlyn's definitions. Any bug in a development version does not really count. Any version that breaks stuff merlyn really cares about clearly is a development version. And the stuff that merlyn cares about is a pretty good test suite for what merlyn actually does. Therefore essentially by definition, he will never be bitten by bugs in Perl.

      VBG

      UPDATE
      I have just been told that this bug is fixed in bleeding edge versions of Perl and will be fixed in 5.6.1. :-)