Re^4: How to do perl -c inside perl?

in reply to Re^3: How to do perl -c inside perl?
in thread How to do perl -c inside perl?

I'm not sure that I see your use case as warranting the check -- I doubt you can report the error any better than perl could when it runs it -- but may be I'm just not getting the full picture.

Historically, the response to the question has been: not safely; but maybe you can do it using Safe which has already been mentioned; or may be you need the expertise and weight of PPI.

If your use case is only ever going to accept strings from a programmer via the command line -- where he could easily just type whatever bad stuff he might give you directly into the command line, or perl, then you perhaps don't need to worry about it. Your call.

But there has been someone (may be you?) asking about accepting code via a web-server and then running it, hence my caution.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong

Comment on Re^4: How to do perl -c inside perl?

Replies are listed 'Best First'.
Re^5: How to do perl -c inside perl? by rockyb (Scribe) on Aug 29, 2012 at 23:44 UTC
Yeah, I'm getting the sense that there is a disconnect somewhere here. Perhaps it's best to acknowledge that and leave it as it is. In the situation of the front-end setup program, `trepan.pl`, before it exec's Perl it does some setup. After it issues exec it has lost control; what is reported by Perl contains some setup code along with Perl code that the programmer specified. Sorting the two can be confusing, especially for novices. Better error reporting is had by `trepan.pl` keeping control and filtering output on failure. In the situation of handling gdb-like condition expressions, displays and watch-points, a syntax error in an expression or statement may mean a very large number of evaluations with the same error before the programmer may have an opportunity to fix the expression. Worse, it may cause the program to continue running where it should have previously stopped. So therefore we don't let such syntactically invalid expressions to get set. Even when expressions and statements are syntactically correct this is still a problem. Whatever a debugger can do to reduce this, like make sure expressions are syntactically correct is well worth the effort in reducing overall programmer and debugger writer aggravation. Safe is interesting but in those cases where syntax checking is not needed but true evaluation is to be done, then what we want is most unsafe. Debugging is inherently unsafe and people want evaluation to done as though it were in the exact context of the stopped program at the point it is stopped, including access to the local variables and the filesystem and OS. Likewise, PPI is also interesting. But quoting from the document cited: The purpose of PPI is not to parse Perl Code, but to parse Perl Documents. Where something like this has been useful in similar debuggers is to be able to pick out subroutine names (via separation of the package name from the subroutine name) or to get code references which can be used to give a listing of those subroutines, give a disassembly of them, or set a breakpoint on them. However I don't think Perl5 has the control over introspection and evaluation that I have needed in Python or Ruby in order to be able to pull this off.	[reply]

Replies are listed 'Best First'.

Re^5: How to do perl -c inside perl?
by rockyb (Scribe) on Aug 29, 2012 at 23:44 UTC

Yeah, I'm getting the sense that there is a disconnect somewhere here. Perhaps it's best to acknowledge that and leave it as it is.

In the situation of the front-end setup program, trepan.pl, before it exec's Perl it does some setup. After it issues exec it has lost control; what is reported by Perl contains some setup code along with Perl code that the programmer specified. Sorting the two can be confusing, especially for novices. Better error reporting is had by trepan.pl keeping control and filtering output on failure.

In the situation of handling gdb-like condition expressions, displays and watch-points, a syntax error in an expression or statement may mean a very large number of evaluations with the same error before the programmer may have an opportunity to fix the expression. Worse, it may cause the program to continue running where it should have previously stopped. So therefore we don't let such syntactically invalid expressions to get set.

Even when expressions and statements are syntactically correct this is still a problem. Whatever a debugger can do to reduce this, like make sure expressions are syntactically correct is well worth the effort in reducing overall programmer and debugger writer aggravation.

Safe is interesting but in those cases where syntax checking is not needed but true evaluation is to be done, then what we want is most unsafe. Debugging is inherently unsafe and people want evaluation to done as though it were in the exact context of the stopped program at the point it is stopped, including access to the local variables and the filesystem and OS.

Likewise, PPI is also interesting. But quoting from the document cited:

The purpose of PPI is not to parse Perl Code, but to parse Perl Documents.

Where something like this has been useful in similar debuggers is to be able to pick out subroutine names (via separation of the package name from the subroutine name) or to get code references which can be used to give a listing of those subroutines, give a disassembly of them, or set a breakpoint on them. However I don't think Perl5 has the control over introspection and evaluation that I have needed in Python or Ruby in order to be able to pull this off.

[reply]

In Section Seekers of Perl Wisdom