using .profile in perl

[Anonymous Monk]

Hello all, I need to do set variables in a perl script. So, I need to do something like this...
. /home/apps/profile
in a perl script. Although this works on the command line, but in the script, when I do `. /home/apps/profile` it doesn't set variables when I call from within this script.
Can anyone offer any suggestions as to why this's going wrong? Thank you all in advance for your time.

[clinton]

You have given us no information about what is in the ./home/apps/profile and how you are calling, but I presume that it contains bash variable assignments (export FOO='bar') and you are using system() or exec() to call it.

These get run in a separate process which runs and exits and does not affect your currently running process.

But it seems silly to use bash to set environment variables from a perl script, when you can do $ENV{FOO} = 'bar'.

You can just open the file, read it in line by line and assign the values to keys of %ENV.

Also, why are you using environment variables? I could understand it maybe if you were possibly calling a non-perl program from your script, but if this is all in perl, why not load your config variables using YAML or YAML::Syck?

use YAML();
our %Config = YAML::LoadFile('./home/app/profile');

and in ./home/app/profile:

---
foo:    bar
arrayref:
   - 1
   - 2
   - 3
hashref:
   foo:   bar
   baz:   bar

Clint

[Anonymous Monk]

ok here's some background on the current situation: We have 2 instances of our application setup on 1 server, but using different ports to use the application. So, rather than having two different logins for each instance, we have created 2 different .profile (ofcourse they both contain different names) The .profile basically sets up the environment values for each instance.
I have a perl script that needs to be run on both instances..but I want to just have 1 version of the script, rather than duplicate the script on both instances. Also, some of the code within script is interrelated...for eg. I may want to call another script within this one, and use that information to do something else on the other instance. That is the reason, I want to source the .profile within the perl script...such that I want to change the environment half way through the perl script.
I hope this helps in your understanding of our problem. Sorry if i'm doing a bad job at explaining, but I'm really new to scripting.

[GrandFather]

You could do something like the following (using ENV rather than foo):

use strict;
use warnings;
use Data::Dump::Streamer;

my %foo = (a => 'b', c => 'd');
my @stack;

my %newFoo = (x => 'b', y => 'd');

push @stack, {%foo};
%foo = %newFoo;
print "Using \%newFoo\n";
Dump (\%foo);

# do stuff with temporary foo

%foo = %{pop @stack};
print "restored original \%foo\n";
Dump (\%foo);

Prints:

Using %newFoo
$HASH1 = {
           x => 'b',
           y => 'd'
         };
restored original %foo
$HASH1 = {
           a => 'b',
           c => 'd'
         };

[brian_d_foy]

You have to set up the environment before you start the process. Child processes can't change the environment of their parents. Create a wrapper for the script to set everything up:

#!/bin/sh

source ~/.profile

perl myscript.pl

[Corion]

If you only need to load the environment settings from that file into your Perl program, tilly's RE (tilly) 3: Get default login environment can help you.

[spiritway]

Are you trying to use the bash .profile file, or are you using a file called './home/apps/profile'? Also, should there be a dot in front of the path? Your title conflicts with the text in your question (the dot, at least, appears to have moved). If this is happening with your path name, then most likely that's the problem. Might it be '/home/apps/.profile' that you're trying to access?

[Rhose]

I'm pretty sure the leftmost "dot" is intentional as the author seems familiar with Unix shell scripting and probably wants to make use of the "dot command" to execute the specified script in the current shell. Without it, the second script runs in a subshell... even though the script may set environment variables, they all go away when the the script ends and the subshell terminates.