I gather you want a command-line script whose behavior will depend on the command-line arguments, and the different behaviors will depend on information that you want to store in distinct files that are separate from the command-line script. That's all fine and easy.

But you seem to want these extra files to be structured as perl code to define hashes. Is there some reason for not wanting to use some other common data file format, such as yaml or json or even xml? (There are good perl modules for these formats, making it easy to store and load any perl data structure you want via a data file.) So long as it's just a matter of selecting one set of data vs. another (including, say, one hash structure vs. another hash structure), reading different data files is the normal way (rather than selecting one vs. another block of perl code to be loaded and parsed after the main script has started running).

For any application where you might want to use one vs. another type of data structure (e.g. hash vs. array), and/or one vs. another set of subroutines, the normal way to do that is to create one or more object-oriented modules, such that there's always a consistent interface between the command-line script and each of the possible (objectified) things that it is supposed to know or do based on command-line args.

Normally, it's fine to load all the alternative modules (via use MyModuleX; use MyModuleY; ...), so that all possible behaviors are accessible on any given run, no matter what the command-line args may be. But if you have a compelling reason to want only the selected data and/or code to be loaded for a given run, just decide how your command-line args will relate to module loading, and then do this: require MyModuleX; (or whatever module), instead of use.