Question

How do I split a long Perl script into two or more different files that can all access the same variables – without having to rename all shared variables from e.g. $count to $::count (or $main::count which is the same)?

In other words, what’s the best and simplest way to split the Perl script into several files without having to import a lot of variables/functions and/or do a lot of manual editing.

I assume it has something to do with making the code part of the same package/scope/namespace, but my experiments so far have failed.

I am not sure it makes a difference, but the script is used for web/CGI purposes and will be running under mod_perl.

EDIT – Background:

I kind of knew I would get that response. The reason I want to split up the file is the following:

Currently I have a single very old and very long Perl file. I know it is not following Perl best practices but it works.

The problem is, I need to distribute the data files it uses between different web servers, first of all for performance reasons. There will be one “master” server and one or several “slaves”.

About 20% of the mentioned Perl file contains shared functions, 40% has the code need to run on the master server and 40% on the slave servers. Therefore, I would like to split the code into three files: 1. shared, 2. master-only, 3. slave-only. On the master server, 1 and 2 will be loaded, on the slaves, 1 and 3 will be loaded.

I assume this approach would use less process RAM and, more importantly, I would minimize the risk of not splitting the code correctly (e.g. a slave process calling a master data file). I don’t see a great need for modularization, as the system works and the code does not need a lot of changes or exchanges with other projects.

EDIT 2 – Solution:

Found the solution I was looking for here:
http://www.perlmonks.org/?node_id=95813

In cases where the main package is in ownership of the variable, the
actual word ‘main’ can be ommitted to yield something like: $::var

It is possible to get around having to fully qualify variable names
when strict is in use. Applying a simply use vars to your script, with
the variable names as it arguments will get around explicit package
names.

Actually, I ended up repeating the our ($count, etc...) statement for the needed variables instead of use vars ();

Do let me know if I am missing something vital – apart from not going with modules! 🙂

@Axeman, Thanks, I will accept your answer, both for your effort and for sending me in the right direction.

Answer 1

Unless you put different package statements in their files, they will all be treated as if they had package main; at the top. So assuming that the scripts use package variables, you shouldn’t have to do anything. If you have declared them with my (that is, if they are lexically scoped variables) then you would have to make sure that all references to the variables are in the same file.

But splitting scripts up for length is a rotten substitute for modularization. Yes, modularization helps keep code length down, but modularization if the proper way to keep code length down–for all the reasons that you would want to keep code-length down, modularization does it best.

If chopping the files by length could really work for you, then you could create a script like this:

do '/path/to/bin/part1.pl';
do '/path/to/bin/part2.pl';
do '/path/to/bin/part3.pl';
...

But I kind of suspect that if the organization of this code is as bad as you’re–sort of–indicating, it might suffer from some of the same re-inventing the wheel that I’ve seen in Perl-ignorant scripts. Just offhand (I might be wrong) but I’m thinking you would be surprised how much could be chopped from the length by simply substituting better-tested Perl library idioms than for-looping and while-ing everything.