On Dec 9, 2003, at 10:09 PM, Pablo Cusnir wrote:
Is there a way using Perl to add to the environment variable PATH a new path, and that addition will be valid after the script is ran and not only for the script's scope. I'm working in cshell in Solaris 5.8
let me see IF I get your idea.
I have a command say "add_path" so that you could do something like
vladimir: 70:] echo $PATH
/usr/local/bin:/usr/X/bin:/usr/bin
vladimir: 71:] add_path
vladimir: 72:] echo $PATH
/happy/place/here:/usr/local/bin:/usr/X/bin:/usr/bin
vladimir: 73:]that's not really going to happen, since you want to change the environment of the currently running process by having a sub-process 'signal it'...
What is relatively 'easy' to do, is to create a sub_shell that will run with a different set of environmental variables.
vladimir: 89:] echo $BOB
BOB: Undefined variable
vladimir: 90:] perl add_path
vladimir% echo $BOB
my bob here
vladimir% exit
vladimir% vladimir: 91:] sed 's/^/### /' add_path
### #!/usr/bin/perl -w
### use strict;
###
### my $path = '/happy/place/here';
### $ENV{PATH} = $path . ":" . $ENV{PATH} ;
### $ENV{BOB} = "my bob here";
### exec("/usr/bin/csh -f");
vladimir: 92:]This is a trick I use when I am trying to run some 'alternative environment' than my default home shell.
But as you notice, it is using 'exec()' to replace the script space a csh that will not source my .login and .cshrc file. It also means that I have a 'double exit' case, where I have to exit out of the current "shell" and then out of my 'default login shell'.
Remember it is easier to change the behavior of a sub_shell than it is to try to signal upwards to some calling shell. Try not to go that way...
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
