Re: "do" what?

Try use vars qw(%config); instead of my.
Update: Also consider turning the file into a package so you could say something like:


use Myconfig qw(%config);

print $config{this}, "\n";
# etc.

## And in your 'Myconfig' package:

package Myconfig;

use strict;
use warnings;

require Exporter;
use vars qw(%config @ISA @EXPORT_OK);
@ISA = qw(Exporter);
@EXPORT_OK = qw(%config);

$config{this} = "that";
$config{here} = "there";
#etc.
1;
[download]

I like this solution better because the place where 'config' is created is self-documenting.
Update: The do block populates a package variable %config in a non-strict environment (your 'do' file), whereas the my creates a lexical variable which never gets populated (I may be wrong, but I think that's it).

Or consider using AppConfig

Comment on Re: "do" what? Select or Download Code

Replies are listed 'Best First'.
Re: "do" what? by cLive ;-) (Prior) on Oct 21, 2002 at 22:19 UTC
wow - that worked. Care to explain why 'my' failed though? I'm puzzled why 'my' kept strict happy, yet didn't populate the hash. cLive ;-) --	[reply]
Re^2: "do" what? by Aristotle (Chancellor) on Oct 21, 2002 at 22:40 UTC
Because my ~~globals~~: lexicals defined outside any blocks are scoped to their file. The file you do'd was compiled without strictures and created a different, global `%config` that it populated. Inside your own file, strict is happy, because you cannot see the global `%config`. Makeshifts last the longest.	[reply]
Re: Re^2: "do" what? by larsen (Parson) on Oct 22, 2002 at 10:02 UTC
Because `my` globals are scoped to a file Maybe I misunderstood your sentence, but `my` creates a lexical, not a global. The difference is perhaps subtle in this thread, but leads to important issues. I often use Coping with Scoping as a reference for this kind of topics. Update: Maybe I should correct and rephrase this reply. The opposition is between lexical and package variables. Since package variables are global, I thought that saying that a `my` variable could be global could drive to misunderstanding.	[reply] [d/l] [select]
Re^4: "do" what? by Aristotle (Chancellor) on Oct 22, 2002 at 12:50 UTC
Re: Re: "do" what? by nothingmuch (Priest) on Oct 21, 2002 at 22:41 UTC
my creates variables only visible to the current scope, and the closures or blocks defined within it. A my variable is not available to anyone outside the scope, or anything called from within the scope, which was not declared inside it (and even so, that gets tricky). Example: `my $var1; $_ = ''; FOO: { my $var2; BAR: { my $var3; local $_ = 'bar set it'; &foo(); } GORCH: { my $var4; } } sub foo { my $var5; print "$_\n"; }` [download] Every scope in the above code can see $var1, because they were all declared under the main scope, in which $var1 was created. However, the main scope, and sub foo cannot see any variables declared within FOO: {}, and FOO: {} cannot see $var5, which was declared in sub foo. Furthermore, BAR: {} AND GORCH: {} can see everything except each other's private variables, and sub foo's $var5. sub foo, even when called from FOO: {}, BAR: {}, or GORCH: {} cannot see their private (my) variables. It can see `local` versions of global (our, $_ sorts) variables though - sub foo, called from bar will print "bar set it". You may also notice, if you `use Data::Dumper; print Dumper \%::;` that any files you `do` are also assigned a package, starting with "_<", and then the relative path. You may be able to use those. my experiments have been unsuccessful, but they weren't very thorough either. Update: I forgot to mention that my and local both create new copies, and new variables, leaving anything with the same name on an outer scope untouched. Also fixed HTML entity. -nuffin zz zZ Z Z #!perl	[reply] [d/l] [select]


laziness, impatience, and hubris
	PerlMonks