exec dynamic script, capture output, but see vars of caller?
 

Hello, I've been tasked with writing a Perl program that generates
another Perl script on the fly (by parsing a file, whose name is passed
to the base script, that is basically a Perl program interweaved in a
document, where the Perl code it inside special tokens (sorta kinda like
how php looks like sitting among html markup.))

I can very easily parse the page using a couple of s/// statements and
such (god I love Perl's native RegEx :-) ) as needed and either execute
with an eval() or dump the code into a file and execute it that.

Now an additional requirement has been tasked on me. The parsed code
needs to be able to 'see' global variables defined in the base script
(most of which comes from a use'ed package lib.)

I thought maybe I have solved this by simply dumping the parsed code
into a file and using it with require, which /does/ work until there's
an error in the code.

I can check the syntax with `perl -c generatedscript.pl` but that's on
compile time. I need to be able to catch runtime errors and warning as
well, in addition to catching it's output, and if there are and errors
or warning, they are to be output in sort of a notice instead of the
output, alerting the end user to a problem in code in the processed
file.

So, I pretty much have all the internals worked out, just this
requirement kinda changes things one me and I've been searching for ours
for a viable (and portable) solution.

Thanks for any advise on this.

--
Stan

Re: exec dynamic script, capture output, but see vars of caller?
 

"Stan R." <stan@invalid.blz/hmrprint/com.com> wrote:
> Hello, I've been tasked with writing a Perl program that generates
> another Perl script on the fly (by parsing a file, whose name is passed
> to the base script, that is basically a Perl program interweaved in a
> document, where the Perl code it inside special tokens (sorta kinda like
> how php looks like sitting among html markup.))
>
> I can very easily parse the page using a couple of s/// statements and
> such (god I love Perl's native RegEx :-) ) as needed and either execute
> with an eval() or dump the code into a file and execute it that.
>
> Now an additional requirement has been tasked on me. The parsed code
> needs to be able to 'see' global variables defined in the base script
> (most of which comes from a use'ed package lib.)
>
> I thought maybe I have solved this by simply dumping the parsed code
> into a file and using it with require, which /does/ work until there's
> an error in the code.

That sounds like a good reason not to use require. But why not use eval
or do?

> I can check the syntax with `perl -c generatedscript.pl` but that's on
> compile time. I need to be able to catch runtime errors and warning as
> well, in addition to catching it's output, and if there are and errors
> or warning, they are to be output in sort of a notice instead of the
> output, alerting the end user to a problem in code in the processed
> file.

Did you have the warnings part worked before you discovered the require
didn't do what you want? If so, why wouldn't that work with eval or do?

One way would be to do add something like this into the code you are
making:

local *STDERR;
open STDERR, ">wherever.err" or die $!;
local *STDOUT;
open STDOUT, ">whereever.out" or die $!;

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB