If you really want to do this, you should use global variables instead. (I.e. use "our" instead of "my")

Thanks for the suggestion.

Just did a "search and replace" on my config file, replacing all "my" with "our", and re-ran it.

Same thing. With the declarations in the config file => non-declaration error messages. Copy and paste the declarations to the main script, runs fine.

Hmmm...




Forget that fear of gravity,
Get a little savagery in your life.

You should also declare the variables in your main file (using "our"), or access them via a $main::varname.
"What should it profit a man, if he should win a flame war, yet lose his cool?"

Can I not declare variables within a 'required' file when running under 'strict'??

You are being bitten by the unrelated lexical scope of required files. Declare the variables you are using in the config file as our variables, and declare them in the main file with our (or better, use vars) also, prior to the require "config.pl" statement. Since you are using them in two files, shared between them, introducing them to both parties using them is not only polite but sensible, and sometimes required, since our variables are lexically scoped, as are my variables - but our variables can be package globals.

Let's read the documentation of our again:

our associates a simple name with a package variable in the current package for use within the current scope. When use strict 'vars' is in effect, our lets you use declared global variables without qualifying them with package names, within the lexical scope of the our declaration. In this way our differs from use vars , which is package scoped.

Unlike my, which both allocates storage for a variable and associates a simple name with that storage for use within the current scope, our associates a simple name with a package variable in the current package, for use within the current scope. In other words, our has the same scoping rules as my, but does not necessarily create a variable.

I read that as meaning that if you don't declare our variables used elsewhere (in a required file) beforehand, they do not necessarily relate to package globals created in the calling scope after the require - when the scope of the required file is no longer in effect. At least, there's nothing in the docs that would guarantee such a behaviour. Update - see Why is 'our' good?.

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Rather than using the vars pragma, I would recommend using package variables:

In config.pl:

package MyConfig;

our %state_name_for = (
           AL => 'Alabama',
           AK => 'Alaska',
           AZ => 'Arizona'
           );
[download]

In your main file:

require 'config.pl';

for my $abbrev ( keys %MyConfig::state_name_for ){
  print $MyConfig::state_name_for{$abbrev};
}
[download]

Using package variables will make your code easier to read, as it will be more obvious where your variables are coming from than if you simply globalize them and will make it less likely that you accidentally update them in your script code.

Better yet, follow The Damian's advice from Perl Best Practices and avoid using package variables, instead, use subroutines or methods in the package containing the variables to access them:

package MyConfig;

my %state_name_for = (
           AL => 'Alabama',
           AK => 'Alaska',
           AZ => 'Arizona'
           );

sub state_name_for{
  return \%state_name_for;
}
[download]

In your main file:

require 'config.pl';

for my $abbrev ( keys %{MyConfig::state_name_for} ){
  print $MyConfig::state_name_for{$abbrev};
}
[download]

This will prevent you from accidentally updating your config variables from your script.

Rather than using the vars pragma, I would recommend using package variables:

In what way are variables declared with the vars pragma not package variables?

This will prevent you from accidentally updating your config variables from your script.

It will also prevent you from accessing the keys of the %state_name_for hash, since in your last example it is a lexical scoped my variable not visible in config.pl.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}