Thanks for the pointer to perlmod. I knew it was there somewhere, I remembered reading it at some point. I just couldn't find it when I wanted it.
Shame about no. I can see how I fooled myself in the first simple test, but for the life of me I cannot explain why it didn't show up in the output from the test program? That's the full, unedited output. I can only imagine that I rolled back the change from POSIX.pm and continued testing stuff...Oh well. I does lead to a another thought on how to prevent use from having an effect. Basically, instead of modifying the use to no, extract the name of the module and preload a local copy of %INC with the module name. That said, it may well be that in the sort of application that I might envision using this for (see further down for a breif description), the use of any use or require or do or INIT/CHECK/BEGIN/END blocks, would be prohibited anyway. So simply detecting them and rejecting the code outright would be the sane thing to do. A pre-defined set of 'authorised modules' would be pre-loaded by the main script and the author(s) of scriptlets (for want of a better phrase) would need to petition for the inclusion of any additional modules to that list.
That still wouldn't address the "\N{some:constant}" thing. I have to admit to never even having heard of that until today. I think that the custom translators stuff looks like it might solve a problem I've been having for a while. That's what I love about this site. It always pulls me in new directions and I end up learning a whole bunch of new stuff each time. Ditto Perl. It never stops coming on.
All pretty academic though, as I still don't see any way around the sub cool () {...} thing.
__DATA__ .v. __END__. I've never had occasion to embed a __DATA__ section in a module, so I'd encountered that distinction.
Gotcha on the INIT/CHECK blocks thing, but as the code being syntax-checked would be eval'd at runtime, the "Too late for ..." warning applies right?
I realise that the pattern I used is still lacking. It would probably need some of Abigail-II's Regex::Common and/or the intreped Mr.Conway's Text::Balanced or maybe Filter::Simple etc. to do the job properly. My main interest in my original post was the use of return; prefixed to the code as a substitute for the eval 'sub {' . $testcode . '}'; that was mentioned and slated elsewhere as a way of preventing the code from being executed.
The OP didn't make it clear why he wanted to do this, but the typical reason given when this has come up before is that they want to store runtime selectable config information. Something like a manually editable version of the sort of stuff that Data::Dumper throws out.
Of course, this would be insane in any environment where the code to be eval'd might come from an 'external' source. There is no sense trying to use this kind of mechanism for 'protection'.
However for "internal-use-only" situations, given that on many platforms, if the user can run the script that would be doing the syntax-checking and evaling, they can also edit it's source, this kind of this kind of approach to "Did they make a typo", has some merit. I think you have proved that there is no possibility of using this mechanism for pre-validating all Perl code. but for the type of use decribed above, and given some sane subset of the language, it may be possible to come up with something that would fit that bill. If everyone throws up their hands and says "It can't be done!", then it never will.
To say that there is no situation when code derived from outside the source of a script should ever be eval'd doesn't--in my eyes at least-- cut the mustard. Once you accept that there is any situation in which you might allow code read in from external to the script --excluding,for example modules in (hopefully protected and verified source) directories--you have to accept that there is a desire to try an validate that external code to at least some degree, before actually running it. If you don't accept any situation in which external code can be eval'd , you have to the start to question the presence of language constructs like do 'file'; etc. and possibly, even eval itself. Personally, the power that eval lends to the language in some situations is just to useful to consider doing away with, but the (currently missing) ability to perform some level of syntax checking without actually invoking the code, would enhance it, to some degree. In reality, it's entirely possible to write totally nonsense code that will pass perl -c anyway, and the types of errors that are discovered at run-time rather than compile-time are usually considerably more invideous. I still couldn't say that -c is non-useful though.
For my own purposes, and the source of my interest in the original post, I want and have started to write my own editor. I would like to use power of perl, it's OO-concepts and a variety of other stuff that I can see how to do easily with perl, from within my editor. (No holy wars, but I will never go back to using Teco-like editors or any of it's derivitives!). I would like to be able to write macros, in perl, in the editor, on-the-fly. I would like to be able to isolate any simple typos and stuff before invoking them. A forlorn hope? I don't think so, but a lot of water will flow under a lot of bridges before I am able to substansiate that. Thankyou for your help in moving my ideas a bit closer to their goal.
<general audience footnote>
As always, the greatest benefit to me personally, of my interactions with perlmonks, is that in short shrift, through the exposure of my thoughts, ideas and code to the assembled populous, I learn more in a day than I would in a week of reading and trial-and error. I sincerely relish the debate that my half-baked ideas generate, and truely hope that I haven't pissed too many (more?) people off by continuing this one. It seems a shame to me that open, free debate is sometimes seen as something other than that around PM, I think this place would benefit from a lot more of it.
</general audience footnote>
Examine what is said, not who speaks.
The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.