Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re: global module variable are imported copies?

by tobyink (Abbot)
on Sep 17, 2012 at 19:29 UTC ( #994083=note: print w/replies, xml ) Need Help??

in reply to global module variable are imported copies?

How exactly is calling There are several ways this can be accomplished. If you're using system(), exec(), qx() or backticks, then they've got no chance of sharing variables. (Not the way you're doing it anyway.) With do "" you'll fare better.

But really, I believe you should rethink your approach to structuring your code. Generally speaking a single process should be a single ".pl" file; ideally only a few lines long. The bulk of code should be organised into reusable modules.

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Replies are listed 'Best First'.
Re^2: global module variable are imported copies?
by perlnub (Initiate) on Sep 18, 2012 at 07:18 UTC
    Thanks guys, Well, the first .pl actually calls a bash script which in turn calls the second .pl script. This is due to bash support for this framework. Quite logical that the Perl variables are not persistent... A file based approach is what I was trying to avoid : ) Maybe I can look into environment variables, but all sound hacky and I should reconsider the whole global idea as usual. Thanks.
      A more significant question in my mind is why is the intermediate bash shell necessary? Can you rework the logic so that perl calls bash and then, once bash finishes, continues on its merry way?

      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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://994083]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2018-03-24 16:41 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (299 votes). Check out past polls.