Here is another example of "#line" closer to your situation. The file
"someotherfile" has embedded perl code (in between the BEGINCODE: and
ENDCODE: markers.) we keep track of where it is in the file, put a #line
directive based on its line numbering in the original file. When an error
message is generated, it is generated based on where it is in the original
file.
andrew@localhost:~$ cat somefile
#!perl -w
open SRC, 'someotherfile' or die;
my @code;
while(<SRC>) {
if($range= /BEGINCODE:/../ENDCODE:/ and $range > 1 and $range !~ /E0/) {
push @code, "#line",$.+1,"\n", $_ ;
}
}
print "executing: @code\n";
eval join "", @code;
die $@ if $@;
andrew@localhost:~$ cat someotherfile
COMMENT:
This file contains a syntax error, no closing curly brace
ENDCOMMENT:
BEGINCODE:
{
ENDCODE:
andrew@localhost:~$ perl -w somefile
executing: #line 6
{
Missing right curly or square bracket at (eval 1) line 3, at end of line
syntax error at (eval 1) line 3, at EOF
andrew@localhost:~$
On Fri, Oct 25, 2019 at 3:34 PM Greg London <em...@greglondon.com> wrote:
>
> Parently my explanation left people confused.
>
> So i have a perl script in one file.
> That script reads a second file.
>
> The second file has blocks of text,
> blocks of code in c++,
> and blocks of perl code.
>
> The script reads the second file
> In its entirety, into an array, and closes the file handle.
>
> The script then looks through the array of text lines
> and decides which block of perl code in the array to eval.
>
> The problem is if the second file has a syntax error in it,
> the script prints out $@ which gives a line number corresponding
> to the start of the string it evaled.
>
> But the string might start on line 538 in the second file.
>
> I thought there was a way to tell the parser to act like
> the current line number is, say, 538, and then follow
> with the rest of the perl code.
>
> I.e. if the error is on line 10 of the string being evaled
> i want the script to report the error was on line 10+538
>
> Because then i open the second file and go to line 548 to see
> where the error occurred.
>
> If perl dies while filehandle is open, it sometimes prints
> out the last line number of the open filehandle.
> But the file is long since closed, and even if it is open,
> the last line read would be the last line of the second file
> before any evals are done.
>
> Basically, i am evaling chunks of perl code out of a file
> and errors are reported as if they were at a line number based on
> the length of the chunk, not where they are actually located in the file.
>
>
> Just before i eval a chunk, the script could prepend.. something...
> That could tell parser to pretend it is starting at line 538
> Even though i only eval a string that is 30 lines of perl code.
>
> I just dont know what ... something... would be.
>
> I swear i did something like this years and years ago
> but cant find it.
>
> Greg
>
>
>
> On Fri, October 25, 2019 11:27 am, Uri Guttman wrote:
> > On 10/25/19 12:22 PM, Uri Guttman wrote:
> >
> >> my understanding (to be corrected by greg) is that an error in evaled
> >> perl code reports the line number in that code. he wants the line number
> >> of the eval call itself. he can use __LINE__ to get that when he checks
> >> the eval for any errors in the slurped in code.
> >
> > another idea:
> >
> > use carp to report the error (or one of the carp subs). check the eval
> for
> > an error and carp $@. it should report the current line number of the
> > eval.
> >
> > uri
> >
> > _______________________________________________
> > Boston-pm mailing list
> > Boston-pm@pm.org
> > https://mail.pm.org/mailman/listinfo/boston-pm
> >
> >
>
>
> --
>
> _______________________________________________
> Boston-pm mailing list
> Boston-pm@pm.org
> https://mail.pm.org/mailman/listinfo/boston-pm
>
_______________________________________________
Boston-pm mailing list
Boston-pm@pm.org
https://mail.pm.org/mailman/listinfo/boston-pm
