never used use strict/use warnings so I'm trying to make it so that the code uses these. Needless to say the moment I add them a bunch of scope errors get thrown

In general terms, I do not think that you need to use the our built-in for what you describe.

Not even if you really need a global hash. You can just make a "global" hash by just declaring it with my at the top-level of your program file (outside of any specific lexical scope).

Or do you have several code files, with use or require relations between them?

Updated for your pleasure!

Alright, you've now changed your original post, so that it is now clear to me that you have a main script and a required module. Maybe that was clear before your changes, but, if so, I clearly did not pick it up.

Well, in this case, yes, using the our function (instead of my) does make sense, it can make the variable available in both code files. Sorry if my previous answer was wrong, I did not understand the full context.

Although, to tell the truth, I am almost never using our to share variables between different compile units. I tend to prefer to create setter and accessor functions and to export explicitly these subroutines, rather than the variables.

You should be able to scope that global with our

our %GLOBAL = {
    dir1 => "/path/to/directory"
    dir2 => "/path/to/another"
};
[download]

You will most likely have more errors to contend with that are not necessarily related. Just deal with them one at a time. (And check in your code each time you successfully remove a compilation error or warning.)

UPDATE!
Why is that hash holding a hash reference? It probably should be either

our %GLOBAL = (
    dir1 => "/path/to/directory"
    dir2 => "/path/to/another"
);
[download]

or

our $GLOBAL = {
    dir1 => "/path/to/directory"
    dir2 => "/path/to/another"
};
[download]

I sincerely hope that was a typo on your behalf, this looks to be a daunting piece of code to refactor.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Hash::Util has the lock_hash_recurse method to enforce such a thing.

That way, you can catch offenders that try to modify the config, and take appropriate action.

I'm afraid you may have misinterpreted what I'm trying to accomplish. There's only going to be one subroutine modifying the has, that's okay. It's a matter of satifying the use strict/use warnings when I try to access members of the hash in other scripts.

Can you post a bit of how the hash is declared in the one script, and how it is used in the other?

Maybe you have

# config.pl
$config{ base_dir } = '/opt/myapp';
$config{ bin_dir } =  "$config{ base_dir }/bin";
[download]

... and then in the main program(s):

require 'config.pl';
print "My config is $config{ base_dir }\n";
[download]

Then you can add use strict to both files if you add use vars '%config'; to both of them.

%main::GLOBAL = (
    dir1 = "/path/to/directory",
    dir2 = "/path/to/another",
);
[download]

sub read_config_files {
    $main::GLOBAL{newstuff} = "a string that was added";
    # etc
}
[download]

# this is file global.pl

use strict;
use warnings;

package GlobalStuff;

%GlobalStuff::GLOBAL = (
    dir1 = "/path/to/directory",
    dir2 = "/path/to/another",
);

# or, alternatively (same thing)
our %GLOBAL = (
    dir1 = "/path/to/directory",
    dir2 = "/path/to/another",
);
[download]

# this is file config.pl

use strict;
use warnings;

require 'global.pl';

read_GLOBAL();
print_GLOBAL();  # for example

sub read_GLOBAL {
    $GlobalStuff::GLOBAL{new} = 'a string';
}

sub print_GLOBAL {
    while ( my ($k, $val) = each %GlobalStuff::GLOBAL ) {
        print "$k => $val\n";
    }
}
[download]

require GlobalStuff;
[download]

If I do this approach will it allow the read_config_files subroutine to modify the hash and the changes will be reflected across all other scripts that access the hash?

Yes, it should work (but why don't you test it?).

Having said that, having a global hash shared among different program files is usually rather poor design. I can't say for sure, because we don't have enough details about what you are doing, but maybe you should share functions accessing to this hash (useing a module), or perhaps think about an OO-implementation.