The only problem, is strict screams about the variable not being declared.

shell> cat > tmp.pl
$foo = "a string";
1;
^D
shell> perl -e 'use strict; require "tmp.pl"; print $::foo, "\n"'
a string
[download]

As for lexical variables declared in another file, they will fall out of scope at the end of a require, as they will no longer be in the file scope as demonstrated in the lexical scoping tutorial. You might also want to check out the first half of the <plug>symbol tables and globs tutorial</plug> for more info on package variables.
HTH

_________
broquaint

# file: MyConf.pm

package MyConf;
use strict;
use vars qw( @ISA @EXPORT_OK @EXPORT  %Conf );

require Exporter;

@ISA       = qw(Exporter);
@EXPORT_OK = qw( %Conf );
@EXPORT = @EXPORT_OK;

$Conf{'foo'} = 'bar';
$Conf{'this guy walks into a'} = 'bar';


# file: test.pl
use strict;
use MyConf;

print "$Conf{'foo'}\n";
[download]

Instead of require-ing the variables from conf.pl why don't you use one of the many modules that let you store and retrieve variables, such as Storable, FreezeThaw, Data::Denter, Data::DumpXML, XML::Simple... or just use your own module, which would then let you export variable as well as functions.

In any case you should pay extra attention to where the data file is located (outside of the web tree is a good idea) and what its permissions are (probaly not writeable by the web server user).

Let me second this! As usual, mirod knows well what he is saying.

I worked on a project earlier this year that had URIs and paths hardcoded throughout the programs. Whenever one program was moved from testing to production, the original coder had spent several minutes manually editing the paths, as the testing and production environments were different. (They should have been the same, but that is a story for another time.)

One of the first things I did was to write a small module based on Data::Denter. It looked in the same location on the production and testing boxes for a configuration file. It loaded all of the configuration values into a hash and made them available. Then, I removed all of the paths and URIs and put them in the configuration file. Finally, I defined constants in all of the programs, and added code to load the configuration module and to populate the important constants.

This turned out to be an even bigger win in one circumstance. I wanted to do some profiling of some detailed code, so I added debugging sections. Because I didn't want to slow things down in general, I used the if (0) {} trick -- and I could control whether or not the debugging code was stripped by the optimizer simply by changing one value in the configuration file.

YAML would be another one I would add to mirod's list.

You might also want to consider one of the Config:: modules as an alternative.

---

(hmmm... just realised that this was my 100th post...)

In your script.cgi:

#! /usr/bin/perl -w
use strict ;
use vars qw( $foo ) ;

do "conf.pl" ;
print "foo is $foo\n" ;
[download]

Those who know that they are profound strive for clarity. Those who
would like to seem profound to the crowd strive for obscurity.
            --Friedrich Nietzsche

Using strict this way requires that all variables are either lexical, fully qualified, or been introduced with use vars. You do neither So, if you insist on using strict, you should obey the rules that are imposed. Also, if you prefer to use strict, why aren't you using it in your conf.pl file?

Abigail

I understand that strict is a tool and using it helps to make sure that I am not doing something that is a violation of reasonably good coding. Therefore using strict helps in saving me extra time trying to debug stupid problems. Now, if you can tell me that you don't spend time trying to debug a stupid error without using strict, then please tell me your secret. Also, the reason I am not using strict in the conf.pl is to allow the requiring of the conf.pl file without strict complaining about the undeclared variables in the conf.pl file. There I am usually certain that the code that is included there is just a list of scalars, arrays and/or hashes.

It wasn't my intention to have the conf.pl file be the issue at hand, but the file that is requiring the conf.pl and using the conf.pl in making the changes to my scripts easier when moving to a new system/rebuild that may not exactly replicate the system that it was previously running on.

Thanks for the criticism,
Matt (mhorner)

YuckFoo

====
MyConfig.pm
====
   package MyConfig;

   my $CONFIG = { color => 'blue', animal => 'camel' };

   *{"::CONFIG"} = \$CONFIG;

1;

====
testit.pl
====
#!/usr/bin/perl

   use strict;
   use MyConfig;

   print "$CONFIG->{color} $CONFIG->{animal}\n";
[download]

# main script
require "conf.pl";
my $conf = get_conf();
print $conf->{foo};
...
# conf.pl
sub get_conf {
  { foo => "bar", color => "red" }
}
1;
[download]