|Pathologically Eclectic Rubbish Lister|
This is a perfect job for a combination of modules and objects. Usually when there is a lot of data that needs to be shared, it is best to encapulate all of it into a single controller class that generates all the necessary objects, manages relationships between them, launches supplemental scripts as needed and so on.
Your main launch script will then be quite simple. It just takes in command line parameters, parses them and sets up a single root object.
Global variables, in and of themselves are not bad, but a massive number of them, especially in the main namespace often signals a design problem in your code. It suggests that you haven't thought through the relationships between the global variables very carefully.
Are they constants? If so, are you cluttering up the global namespace with constant names and preventing your submodules from using those names for their own purposes? Perhaps it would be wiser to place the variables in a package and declare them as our variables. That way they still can be read by all your programs but you don't clutter up the module namespace.
If they are not constants, do they all work in concert? If so, why aren't they encapsualted in an object? If not, why is the relationship between them and why do you need so many?
There may be good reasons for making that single root object a global variable, especially if you declare the variable as an our variable in a package other than main. For example, many application API's have a single $myApp or $SOME_PACKAGE::approot variable. Any script that needs to interact with the application simply makes calls on the $myApp object.
Are you familiar with perltoot? If you are new to objects and classes in Perl, that might be a good place to start.