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
Re: [Boston.pm] environment variables that stick
On Wed, Jan 15, 2003 at 11:36:29AM -0500, [EMAIL PROTECTED] wrote:
I want to write a perl script to
replace a Unix shell script which
does nothing other than create
and set environment variables.
So the perl script might look something like this:
$ENV{GREGSVAR}='Hello';
except that when I run the script, the
assignment doesn't seem to stick, and
the environment variable GREGSVAR doesn't
exist after the perl script is finished
executing.
looking up environment variables in the
perl bible and the perl cookbook didn't
show anything about sticky environment variables.
can this be done in perl?
Check the FAQ (perldoc -q environment):
I {changed directory, modified my environment} in a perl
script. How come the change disappeared when I exited the
script? How do I get my changes to be visible?
Unix
In the strictest sense, it can't be done--the
script executes as a different process from
the shell it was started from. Changes to a
process are not reflected in its parent--only
in any children created after the change.
There is shell magic that may allow you to
fake it by eval()ing the script's output in
your shell; check out the comp.unix.questions
FAQ for details.
Ronald
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
RE: [Boston.pm] environment variables that stick
Probably not.
Depending on the script you're trying to replace (really, depending on the
shell it's supposed to run under) you'll find that it is sourced in some
way... Which means that the commands are really executed in the initial
shell, rather than a subshell/child process (which is what usually happens
for shell scripts, and always for anything else, such as a Perl program).
There is no way of manipulating the state of the parent process (the shell
you're trying to have an effect on).
What's the script like? If it's Bourne-shell based (i.e. expected to be run
from a sh, ksh, bash, or similar) it's probably invoked by prepending a dot
and a space . . That means run the lines in this file as though I had
typed them on my command line. If it's a csh/tcsh one, it's probably
source and then the script name.
Perhaps someone will correct me if I'm leading you astray. But I'm pretty
sure you can't do what you want to do.
The only way you can do what you want in Perl is to set all those
environment variables, and then fire up the command that you want to run
afterwards from *inside* your Perl. That way it is a child of your Perl
script, and inherits all the variables you set.
You could presumably fire up a new shell process, and this would do what you
want.
But in most situations I can imagine you're looking at, this isn't an
option.
Hope this helps philipp
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 11:36 AM
To: mongers of perl
Subject: [Boston.pm] environment variables that stick
I want to write a perl script to
replace a Unix shell script which
does nothing other than create
and set environment variables.
So the perl script might look something like this:
$ENV{GREGSVAR}='Hello';
except that when I run the script, the
assignment doesn't seem to stick, and
the environment variable GREGSVAR doesn't
exist after the perl script is finished
executing.
looking up environment variables in the
perl bible and the perl cookbook didn't
show anything about sticky environment variables.
can this be done in perl?
Greg
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] environment variables that stick
It strikes me that 'exec' replaces the current process with another process,
I believe inheriting the existing environment.
You miht try making the last line of the perl script : exec your follow-on
process here so that it gets the environment that you set within the script.
Vince
On Wednesday 15 January 2003 11:36 am, you wrote:
I want to write a perl script to
replace a Unix shell script which
does nothing other than create
and set environment variables.
So the perl script might look something like this:
$ENV{GREGSVAR}='Hello';
except that when I run the script, the
assignment doesn't seem to stick, and
the environment variable GREGSVAR doesn't
exist after the perl script is finished
executing.
looking up environment variables in the
perl bible and the perl cookbook didn't
show anything about sticky environment variables.
can this be done in perl?
Greg
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
