AFAIK, you can't. The BEGIN subs need to execute as they have the potential to warp the syntax.

Seems (to my unfamiliar-with-internals eyes) like it wouldn't be too much of a stretch to have a check option for each phase, so you could syntax-check only the BEGIN phase, for example. I don't even know in what order BEGIN, CHECK, and INIT get run, but each setting would only run "up to" whatever phase you're interested in.

Would someone who has a better understanding comment on whether that's doable?

Update: Looks like people know enough to downvote, but not enough to explain. That's never happened before.

---

Caution: Contents may have been coded under pressure.

I think the down votes are because a) syntax checking only through BEGIN, CHECK, INIT doesn't solve the OP's problem and b) because you said you don't know what order BEGIN, etc run in when it's easily discoverable from the docs (never admit weakness ;-).

Though, in any case your post does present a potential "solution". The OP could modifiy the modules such that any initialization code is in an INIT block rather than free of subroutine shackles and so executed at module use-time. Of course, this is assuming that the code really isn't warping the syntax of the language to its own nefarious desires and really isn't setting up structures needed by future BEGIN-time processes.

In some sense, perhaps "free" code in modules should automatically be placed in INIT blocks and the module author, if they really need BEGIN-time processing, should be required to say BEGIN { ... }. I'd wager that that's what many people mean with "free" code anyway.

duff

unlink("myfile") unless $^C;
[download]

I haven't seen much mention of $^C in the past, so perhaps someone more knowledgable can comment on whether this is always effective.

IMO it is a module writer's responsibility, if at all possible, to allow the module user to check their own code without side effects.

That assumes no incompetence or malice on the part of the module writer. One of the first tests of competence is to see if the module is will actually pass a syntax check.

The problem of how to do that safely is really the one I'd like to address.

If you are worred about incompetance or malice, you better visually inspect the module and the Makefile that comes with it (I certainly do). Syntax checking is great for finding bugs during compiling your own code, but don't confuse it with keeping things safe. In fact the safest code is code that fails a syntax check.

Syntax checking can't stop someone from writing syntactically correct, non-BEGIN block, destructive code. All they have to do is bury something like system("rm -rf *") in the module somewhere and you will have lots of fun trying to find out why your system doesn't work.

Why write a separate Perl script? Turn this into a module that sticks a codref in @INC to filter the BEGIN blocks into harmless normal subroutines. Acme::Incorporated shows how.

Yuck. Isn't there an option to the syntax checker to just, you know, check the syntax without actually running anything? :-(

Is anyone working on this?

I think you might have missed the point about begin blocks. In order for perl to check syntax it HAS to run the use statments, because the use statments can change perls syntax. Thinks like subs in the modules included could add behaviour to bare words, especialy subs with prototypes.


___________
Eric Hodges