Of course, that's a procedural short-cut -- a relatively messy expedient. A theoretically cleaner, more maintainable solution is that the various subroutines stored in separate files would be modified not to use global variables. Instead, to get a fully satisfying solution, you would do one of the following:

• if the subroutines are using (and modifying) global variables "owned by" (first declared in) the main code file, then each of the subs (and sub calls) would be modified so that those globals are passed (by reference) as parameters to the subroutines, or
• if the subs are "creating" global variables that are subsequently used in the main code (a particularly nasty habit, IMHO), they would be organized into packages (typically one package per source file, but you can choose to have one source file with multiple package ... declarations) and would be "objectified" so that the variables they create are accessible via objects that are given to the caller via a "new()" function (which is surprisingly simple to do), or
• some combination of the above, depending on what your current "require"d files are doing.

If that raises any procedural questions for you, please post some relevant code to demonstrate the issue.

(P.S. (update): Welcome to the Monastery! I could tell right away that you're a new monk, because if you'd been around longer, you would have heard about "use strict" earlier...)

I've separated subroutines into several files that I load into the main script using require

I have some global variables that I define in the main script, and that are used throughout the sub-scripts

I heard, for the first time, that it's good practice to "use strict"

use strict;
$main::foo = 'bar'; # that's ok
[download]

use strict;
$foo = 'bar'; # error!!! it doesn't work with strict pragma!
[download]

#!/usr/bin/perl

use strict;
use pkg1;

$main::foo = 'bar';

print pkg1_get_foo()."\n";
[download]

use strict;

sub pkg1_get_foo {
    return "From pkg1: $main::foo";
}

1;
[download]

See our also!

"use ModuleX;" is a compile thing. And Module X will be compiled. require is a run time time thing - as far as I know.

Most of my modules (but not all) are function oriented as opposed to OO. These modules export subroutine names that can be used by the "caller", the Perl code that "uses" the module can access these symbols. I can export function names or actually even "our" variables and I can export names either by default or by request.

If I have an procedure oriented module, your interface to is is only via the symbols that I chose to export or allow you the import optionally. Basically exporting those symbols means that these name go into the package name space.

An OO module is different in that not every method is necessarily in a symbol in the package table and there is more overhead to call a method in an OO package.

When I "use ModuleX", it gets complied and executed. Require means that it must be there, but no code within it will be compiled and run until it is needed in the code.

Normally you should "use" modules that you write yourself. "require" is actually a kind of "rare duck" and is used in special circumstances.

my $ProgramDir;
BEGIN{
   ($ProgramDir) = ( $0=~m|(.+)\/.+$|, $0=~m|(.+)\\.+$| ,".");
}
use lib ( $ProgramDir, ); # Current Program's Dir
use MyModule ("$ProgramDir/MyModule.db3");
[download]

!/usr/bin/perl -w
use strict;
use warnings;
use Class::DBI;

package MyModule;
our $DBPath="MyModule.db3"; # Default file nme
sub import{
   my ($class,$newpath)=@_;
   $DBPath = $newpath || $DBPath;
   ## print "IMPORT: Setting path to '$DBPath'  \n\t \n";
   ## Delay this setting till AFTER IMPORT !!
   MyModule::DBI->connection(qq|dbi:SQLite:dbname=$DBPath|, "", "");
}
[download]