in reply to Re^2: global module variable are imported copies?
in thread global module variable are imported copies?
In this context, my solution won't work because it only serializes the value upon exit. You should probably write an accessor method in your globals module so that, regardless of how your export scheme works, changes to your variable are propagated.
At the end of the day, the methods that sound cleanest to me are command line parameters or environment variables, depending on some secondary concerns like existing codebase. Setting environmental variables in Perl is as simple as modifying/reading the %ENV hash; e.g. perl -e '$ENV{HELLO} = "Hi\n"; system(q{echo $HELLO})' So, modifying my code from above, your module might read
#!/usr/bin/perl package subs::utils; use strict; use warnings; BEGIN { require Exporter; # set the version for version checking our $VERSION = 1.00; # Inherit from Exporter to export functions and variables our @ISA = qw(Exporter); # Functions and variables which are exported by default # exported only if fully qualified our @EXPORT_OK = qw(get_henky set_henky); } $ENV{HENKY} //= "henky_init"; sub get_henky {return $ENV{HENKY}}; sub set_henky {$ENV{HENKY} = shift}; 1; # return a true value, standard module behaviour
Update: But I neglected to point out that changes to the variable won't propagate back up the shells, since a change in a child's environment don't affect the parent. For example: perl -e '$sq=chr 39; $ENV{HELLO} = "Hi\n"; system(qq|perl -e ${sq}print \$ENV{HELLO};\$ENV{HELLO} = "Yo\n";print \$ENV{HELLO}${sq}|); print $ENV{HELLO};' outputs
Hi Yo Hi
#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.
|
|---|