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

[rockyb]

I think what was meant is that exit() sometimes can prevent syntactically (correct) code from being executed. It is also true that sometimes it does not. Human language can be frustratingly ambiguous and imprecise: the quoted statement could have implied sometimes but not all, or it could have been intended to mean all.

One can gain a few Karma points on PerlMonks here and there by finding mistakes, possibly by a imposing a slightly different or more rigourous interpretation, and possibly attached to side points. Where it to be so easy to reach true Nirvana that way.

What I have been seeking a deeper understanding what is going on inside Perl and perl -c with the hope to coming to a simpler, more reliable means to test whether a string is a Perl statement or expression. After all, eval() has to go through a syntax check its course its existance. If this question has been asked several times before and the best that had been suggested has been perl-c (which is really not that bad or the end of the world), then I think we can do very small bit better by creating a simple Syntax::Check module. That this might be of help to the broader community is more important to me than the PerlMonks Karma points in correcting someone here or there.

I am also optimistic that there might (one day) be a way to just ask Perl to do syntax check part that it does for eval() without the evaluation part.

With all of this behind, it has become clear that yet again, I have not fully explained my situtation and the problem I'm trying to solve.

I really do want to just check whether something is syntactically correct. No evaluation should be done. Therefore solutions with eval() which can have side effects are probably not good. And devilish kinds of expressions and Perl programs probably also have to be properly handled

So let me make try to again to explain this in a very specific setting without trying generalize. In contrast to the stock Perl debugger perl5db, Devel::Trepan has a front-end program called trepan.pl that does the setup for Perl debugger invocation. This allows one to specify simple debugger options like whether terminal highlighting is desired. But before trepan.pl takes the plunge into exec to reinvoke Perl with the appropriate flags, it checks to see if the eval string or Perl program is valid. That way it can report back a more reasonable and controllable error message.

There are a couple of other situations where syntax-only checking is needed. Breakpoints can have conditional expressions associated with them that determine whether to respect or ignore the breakpoint. These expression are evaluated in a context that can be totally different from the context inside the debugger where a programmer specifies what to test for. So an eval inside the debugger of say $a may result in an unbound variable, whereas at the point a breakpoint occurs that variable may be defined and have a value. Similarly, one can ask the debugger to run specific Perl statements in the context of the current stopping point of the program. In gdb terms these are called display expressions. In perl5db, they are called actions.

[BrowserUk]

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.

[rockyb]

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.