Configuration question

[chatiman]

Hello,

I'd like to put all the configuration variables in a separate file.
The configuration file will contain etheir a hash:
%conf = ( ... )
or constants :
use constant { ... }

How can I do that in perl without the "dirty":
eval (`cat ...`)
?

Thanks

 

[Beable van Polasm]

Hello,

I'd like to put all the configuration variables in a separate file.
The configuration file will contain etheir a hash:
%conf = ( ... )
or constants :
use constant { ... }

How can I do that in perl without the "dirty":
eval (`cat ...`)

You could make it into a module. See "perldoc perlmod", and
"perldoc perlmodlib".


--

 

[fifo]

I'd like to put all the configuration variables in a separate file.
The configuration file will contain etheir a hash:
%conf = ( ... )
or constants :
use constant { ... }

How can I do that in perl without the "dirty":
eval (`cat ...`)
?

perldoc -f do

 

[chatiman]

do doesn't reexport variables set from a files if I remember.

I would like a function like this but which does :
eval (`cat ...`)

 

[chatiman]

You mean make a module and than export the variable ... that's nice I didn't
think about it

Thanks

"Beable van Polasm" > You could make it into a module. See "perldoc
perlmod", and

 

[Uri Guttman]

c> do doesn't reexport variables set from a files if I remember.
c> I would like a function like this but which does :
c> eval (`cat ...`)

huh????

what do you think do does? and how is it different than that code (other
than being faster)? and what in the world does 'reexport' mean? and if
you don't remember, look it up in the docs and relearn it.

uri

 

[chatiman]

Well, english is not my native language. I understand it a bit so excuse me
if I misunderstand the following words from perldoc -f do :

""do FILENAME" cannot see lexicals in the enclosing scopre; "eval STRING"
does.

Which I translate (that's probably wrong) as :
- When a file evaluated with "do" sets a variable, you cannot see this
variable from the file that called "do"
.........

c> do doesn't reexport variables set from a files if I remember.
c> I would like a function like this but which does :
c> eval (`cat ...`)

huh????

what do you think do does? and how is it different than that code (other
than being faster)? and what in the world does 'reexport' mean? and if
you don't remember, look it up in the docs and relearn it.

uri

http://jobs.perl.org

 

[Ben Morrow]

c> do doesn't reexport variables set from a files if I remember.
c> I would like a function like this but which does :
c> eval (`cat ...`)

what do you think do does? and how is it different than that code (other
than being faster)?

ObPedant:

perldoc -f do:
| except that it's more efficient and concise, keeps track of the
| current filename for error messages, searches the @INC libraries, and
| updates %INC if the file is found.



Ben

 

[fifo]

Well, english is not my native language. I understand it a bit so excuse me
if I misunderstand the following words from perldoc -f do :

""do FILENAME" cannot see lexicals in the enclosing scopre; "eval STRING"
does.

Which I translate (that's probably wrong) as :
- When a file evaluated with "do" sets a variable, you cannot see this
variable from the file that called "do"

No, it means you can't see _lexical_ variables, i.e. those created using
"my". Packages variables, like those in your original example, will be
visible.

 

[Ben Morrow]

[stop top-posting]

Well, english is not my native language. I understand it a bit so excuse me
if I misunderstand the following words from perldoc -f do :

""do FILENAME" cannot see lexicals in the enclosing scopre; "eval STRING"
does.

Which I translate (that's probably wrong) as :
- When a file evaluated with "do" sets a variable, you cannot see this
variable from the file that called "do"
........

You do misunderstand. What this means is that if you have

file1:
my $var1 = 'hello world';
do 'file2';
print $var1;

file2:
$var1 = 'foo bar';

then the code in file2 will not be able to access $var1 from $file1. If
you are using constants, which are subs, this will not affect you; if
you want variables to pass between files they should be package globals
('our' variables) rather than file lexicals ('my' variables), viz.:

file1:
do 'file2';
print $var;

file2:
our $var = 'hello world';

Note that even when using eval `cat file`, lexicals cannot pass out from
the included file to the including file, that is

file1:
eval `< file2`; # no need for useless-use-of-cat
print $var;

file2:
my $var = 'hello world';

will *not* print 'hello world'.

Using a module to hold the config information is better again, though,
as it allows you more control over which bits of config information you
import into your namespace at a given time.

Ben

 

[Joe Smith]

do doesn't reexport variables set from a files if I remember.

I'd say you remember incorrectly.
do $file or die "Unable to process $file - $!";
Does not import() or export() anything; variables are
added to the current symbol table directly.
-Joe