note armstd <p>I've seen pretty good direct debugging suggestions already, so I'll go a bit off topic here... </p> <p>You've mentioned you have other BEGIN blocks already. What do your BEGIN blocks DO? And why? I'll also point out that code in a module that isn't confined to a sub in a module will execute at "compile time" for the <b>caller</b>, just after the BEGIN blocks in the current module. It's important to understand that Perl can (and usually does) have multiple "compile time" phases interspersed with "run time" phases. </p> <p>Do you have any code that isn't in BEGIN blocks or sub blocks in your modules? Do you realize that will also execute at your caller's "compile time" (actually at the module's run time, but prior to the 'use Module;' returns to the caller)? The standard "1;" we put at the bottom of a Module is executed in that module's run time, for instance. </p> <p>Generally I don't recommend doing anything at all at compile time other than: <ul><li>declare package/code structure - package namespace, base class, exports, pragmas</li> <li>declare package globals - 'my' wherever possible, 'our' if absolutely necessary, initialized undef</li> <li>declare/initialize package global constants</li> <li>declare subs</li> </ul> Anything not on that list... is either extremely exceptional, or violates one of my design principles. Anything that involves doing anything beyond simple declaration... save it for runtime. Your methods will know when runtime is happening, because they won't get called at any other time. Do object initialization at first method call. Do package initialization at first object initialization. If no method is ever called, be glad you saved all that time and effort. </p> <p>So my big question is, what are your modules doing outside of that list of declarations? Does it really need to be done at "compile time"? I've seen cases where the designer had modular concrete subclasses "registering" themselves with their abstract class at compile time, as one example. Perl allows other ways to do that kind of thing though. Compile time in Perl is precious, and should not be abused. It delays response-time in interactive programs and CGIs. In my experience, the less that gets done at compile time in Perl, the better. </p> <p>Do any of your Modules use shift() or pop() outside of a sub? In the package global space, @ARGV can work for shift/pop like @_ does inside a sub, as a convenience. Here's an example of a badly behaved module: </p> <code> $ cat Module.pm package Module; our $global = shift(); # stole the first arg already... while( $arg = shift() ){ print "Module stealing arg: $arg\n"; }; 1; $ $ perl -e 'BEGIN { print "\nbefore using my module: ".join(", ",@ARGV)."\n" } use Module; BEGIN { print "\nafter using my module: ".join(", ",@ARGV)."\n" } print "Module::global: $Module::global\n";' one two three before using my module: one, two, three Module stealing arg: two Module stealing arg: three after using my module: Module::global: one $ </code> <p>I would recommend breaking down your modules. Start over, recreating them from the ground up, cut&pasting bit by bit. Create a main caller that only looks at @ARGV and compiles the modules like mine does above. Reconstruct the modules from scratch, Starting with just package structure (package declaration, base class, exports) and subs. See what happens. Add package global my/our declarations. See what happens. What's left, and why? Does it need to be done at compile time? </p> <!-- Node text goes above. Div tags should contain sig only --> <div class="pmsig"><div class="pmsig-901898"> <p> --Dave </p> </div></div> 920783 920783