Re: [Boston.pm] environment variables that stick
You *could* have the perl script set all of the environment variables, then exec a new shell. ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] environment variables that stick
At 09:51 AM 1/16/2003 -0500, [EMAIL PROTECTED] wrote:
Hanes, Philipp wrote:
Probably not.
Hi Philipp, how're things?
That's a bummer.
TMTOWTDI becomes NCD - No Can Do
If it is any consolation, it isn't Perl's fault. It is inherent in the
nature of parent/child processes. The child cannot update the parent
environment.
What's the script like?
it's a hodgepodge of several scripts, actually.
each one is intended to support a specific tool,
setting environment variables, paths, etc.
We'd like to make them more intelligent, and
I figured perl would make it a lot easier,
especially since I don't know shell programming.
Oh well, guess I'll have to learn it.
You'll want to devise a settings subsystem. If your scripts run in
multiple operating environments (DEV vs. TEST vs. PRODUCTION), you want to
be able to specialize the settings without re-specifying everything from
scratch. Btw, Perl syntax is excellent for this purpose. The module
compilation system also lends a hand.
Example:
# Config.pm - Settings for the Foo system
package Foo::Config;
use vars qw( $HomeDir $LogDir $Foo %Baz @Bar );
BEGIN
{
$HomeDir = '/usr/local/foo';
$Foo = 'foo';
@Bar = ( qw(Foo Baz Bar) );
%Baz = { Foo = $Foo, Bar = \@Bar };
}
#--
# Override defaults with local settings file
#--
BEGIN
{
# Override $HomeDir and other Foo settings
my $cmmd = $ENV{HOME}/.foorc;
if ( -e $cmmd )
{
my $rc = do( $cmmd );
if ( $@ ) {
die Couldn't parse perl script $cmmd: $@;
}
if ( !defined( $rc ) ) {
die Couldn't do file $cmmd: $!;
}
# The following logic doesn't work under
# some versions of mod_perl
# if ( $rc ) {
# die Couldn't run perl script $cmmd: $rc;
# }
}
}
#--
# Fixed relative paths or things that cannot be localized
#--
BEGIN
{
$LogDir = $HomeDir/logs;
}
1;
Your various modules and programs now just use Foo::Config; and can refer
directly to variables $Foo::Config::LogDir, etc. Works great for letting
programmers each run in their own work area while keeping the Config
structure intact in all environments.
hth,
Charlie
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] environment variables that stick
On Thu, Jan 16, 2003 at 09:59:52AM -0500, Ron Newman wrote:
You *could* have the perl script set all of the environment
variables, then exec a new shell.
Abigail came up with quite a neat move involving a double exec written
up on Fun With Perl list. In hir own words,
From: abigail[at]foad.org
Date: Tue, 19 Mar 2002 07:46:36 +0100
To: ianb[at]ot.com.au
Cc: fwp[at]perl.org
Subject: Re: Non-golf fun
Reply-To: abigail[at]foad.org
References: [EMAIL PROTECTED]
On Tue, Mar 19, 2002 at 10:46:04AM +1100, ianb[at]ot.com.au wrote:
In an attempt to stimulate non-golf threads:
.. Has anybody done any really interesting Perl hacks that they are
proud of?
Yeah, I do actually. Recently I was writing a program that needed
to (shell) source a file, to get some environment variables set,
and use those variables in further calculations.
I could of course have written a shell wrapper that sourced the file,
then started my program. But I decided I just wanted a single program.
To source a shell file, one cannot use 'system' - that would start
a child process, and setting the environment in the child is pointless.
So, I decided to use a trick, a double exec. First I exec a shell
that is sourcing the file with the environment variables, then I
exec the original program - with a special argument to indicate the
variables have been set.
The relevant part of said program follows.
Abigail
my $ENVIRONMENT = /some/file/somewhere;
if (@ARGV $ARGV [0] eq '--sourced_environment') {
shift;
}
else {
if (-f $ENVIRONMENT) {
#
# Now we perform a double exec. The first exec gives us a shell,
# allowing us the source the file with the environment variables.
# Then, from within the shell we re-exec ourself - but with an
# argument that will prevent us from going into infinite recursion.
#
# We cannot do a 'system source $ENVIRONMENT', because
# environment variables are not propagated to the parent.
#
# Note the required trickery to do the appropriate shell quoting
# when passing @ARGV back to ourselves.
#
@ARGV = map {s/'/'''/g; '$_'} @ARGV;
exec --;
source '$ENVIRONMENT'
exec$0 --sourced_environment @ARGV;
--
die This should never happen.;
}
}
/lurk,
--
Paul Makepeace ... http://paulm.com/
If I had new shoes, then you should, too.
-- http://paulm.com/toys/surrealism/
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] environment variables that stick
Unix folks are used to these limitations on how you can use environment variables. Do things work the same way in Windows? ___ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] environment variables that stick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Charles Reitzel [EMAIL PROTECTED] writes:
[snip]
BEGIN
{
$HomeDir = '/usr/local/foo';
$Foo = 'foo';
@Bar = ( qw(Foo Baz Bar) );
%Baz = { Foo = $Foo, Bar = \@Bar };
}
[snip]
The %Baz is broken; it should be
%Baz = ( Foo = $Foo, Bar = \@Bar );
since it's a hash, not a reference to a hash.
- --
John Abreau / Executive Director, Boston Linux Unix
Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9
PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iQCVAwUBPibwsVV9A5rVx7XZAQLHnQQArcRVA0bIeQseS5VehUrgWGbDUTGxSBTl
2TeD98HLZ9wa9LJSm5yp0TiZ7CFvdcuxWFMfphF5AScP8Jpn6J+pacD70ZhHJqWK
hBz9R96FISPj0mkYDYNFq1/5VnAtnnp8pdwEFUyKDnkWHQDOrywoeAQMS0zxPL3f
hWanAUyo04g=
=9dV3
-END PGP SIGNATURE-
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
