Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Parent Process Environment

by Ronnie (Scribe)
on May 02, 2006 at 09:40 UTC ( #546849=perlquestion: print w/replies, xml ) Need Help??
Ronnie has asked for the wisdom of the Perl Monks concerning the following question:

I'm trying to use the code Tilly supplied re picking up an environment from a parent process - I tried this some time ago but time was pressing so I ended up just creating the environment by copying the details from the shell script into my own Perl version....tedious beyond belief! I'm now working on a much bigger application who's default environment is created by 2 shell scripts and would be WAY too tiresome to replicate. I think I know what her script does but wondered if the error I'm getting is as a result of how our environment looks.


Yes before anyone else tells me, it's a mess but it's supplied by a third party and we are NOT allowed to change it.....
The code I'm using for test purposes is -
#!/usr/bin/perl -w # use strict ; # sub get_login_env { local %ENV; # my $shell = shift || (getpwuid($<))[8]; # # I know that the shell we use is the ksh # # my $shell = '/bin/ksh' ; my $env = `echo env | perl -e 'exec {"$shell"} -sh'`; if (wantarray) { my @pieces = ($env =~ m/^(.*?)=((?:[^\n\\]|\\.|\\\n)*)/gm ); s/\\(.)/$1/g foreach @pieces; return @pieces; } else { return $env; } } # # Variables #----------# my $result = undef ; # Processing #----------# print "\n\t\tPlay with ENV starts\n" ; $result = system(". /opt/bin/oraIHSLIVE.env") ; # print "\n\tRES :: $result\n" ; if ($result) { print "\n\t\tRes :: $result\n" ; print "\n\t\tBombing Out (1)\n" ; exit 122 ; } # $result = system(". /opt/bin/fsw.env IHSLIVE") ; # if ($result) { print "\n\t\tRes :: $result\n" ; print "\n\t\tBombing Out (2)\n" ; exit 123 ; } # %ENV = (%ENV, get_login_env()); print "\n\t\tPlay with ENV ends\n" ;
This produces an error which I'm guessing may be caused by the format of our packages environment.The error generated is
$ Play with ENV starts RES :: 0 Environment variable ADMIN_DIR is not set grep: can't open a grep: can't open tty Play with ENV ends
Ignoring the ADMIN_DIR message - well we do apparently! - does this mean that tilly's code won't work with the format of our environment? If so I suppose I better get typing....for the next X days!

Replies are listed 'Best First'.
Re: Parent Process Environment
by bart (Canon) on May 02, 2006 at 09:56 UTC
    Instead of parsing the script, couldn't you just run it, and list the environment values at the end? You can do that by running another script in the same system or qx call. Something like this (untested — well, the perl oneliner has been tested):
    my $env = ` && perl -MData::Dumper -e '$Data::Dumper::Ters +e=1; print Dumper \%ENV'`;
    You can then eval the string representation of the anonymous hash you captured into $env. You may have to suppress output from the shell script.

    And on some platforms, %ENV is magical, so you might not be able to pick up the whole environment. All you can do, is test.

Re: Parent Process Environment
by Tanktalus (Canon) on May 02, 2006 at 15:03 UTC

    We solved a similar issue pretty much backwards from you. And, from the sounds of it, you may not have the freedom to do this, but others who read this may, so I'll write it down for posterity.

    Over the last 5 years, we have moved from a shell-based automation system to a perl-based one. However, there was an intermediate stage where it was hybrid, and we needed to do likewise: share a bunch of variables. Lots of variables. Hundreds of them, actually.

    What we did was move all the variables to perl. Move, not copy. Actually, we moved them to a data file (e.g., XML) that perl would read and parse. The reader was one module, the parser another. And then we wrote a shim program that would call all the readers (which would call all the parsers) and eventually gather all the information that the shell scripts might need. This actually would take a few seconds. And then it would spit out a shell script with a bunch of "VAR=value\nexport VAR" text.

    We tore out all the variable setting from the shell scripts, and replaced it with three lines:

    ./ [...] > /tmp/automation-$$ . /tmp/automation-$$ rm /tmp/automation-$$
    It wasn't cheap to do this, but it was worth it when we could guarantee that only one value of a variable existed in our environment, and by changing that one, centralised value, we knew that everyone that needed it would have the right value.

    Since then, we've managed to replace the rest of the shell code, and the shim is gone. But it helped a lot for the phase we were in.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://546849]
Approved by Tanalis
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (6)
As of 2018-07-16 20:51 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (349 votes). Check out past polls.