There actually is a way on Win32 platforms, thanks to Mr. Roth exposing
an API via Win32::AdminMisc. The key is whether an application pays
attention to it - many only look up a variable at invocation or first
use. I do not believe simply re-referencing the variable in the code
would help - it would have to be reacting to the broadcast, then
updating it's own copy of the variable. Here's Dave's documentation
from the AdminMisc FAQ. Sorry to post it instead of the link, but
Dave's site is still down. Anyone know what's going on with it?
SetEnvVar( $Name, $Value [, $Type [, $Timeout ] ] )
This will set an environmental variable $Name to $Value. This function
will set the variable (creating it if $Name does not exist).
The new value will be set globally so all applications will be able to
use it, unlike setting $ENV{xxx} -- which sets the variable for the
current process and any children it spawns afterwards.
When this function is called a broadcast to all running applications is
made telling them about the variable change. An application may choose
to ignore the change if it was programmed to do so.
If $Timeout is specified then the broadcast announcement will be aborted
if it takes longer than $Timeout seconds (some applications may be in a
hung state so they can not acknowledge the broadcast). If this timeout
occurs the variable will still be updated but broadcasting it's change
will be aborted.
If $Type is specified it can be one of:
ENV_SYSTEM
Specifies that $Name will be a system environmental variable. (default
if $Type is not specified)
ENV_USER
Specifies that $Name will be a user environemental variable.
This function is the equivalent to setting an environental variable in
the control panel's system applet.
NOTE: Your script will not see the new value. For that you should set
$ENV{xxx}.
Example:
Win32::AdminMisc::SetEnvVar("Temp", "$ENV{HOMEDRIVE}$ENV{HOMEPATH}",
ENV_USER, 10);
Returns:
0 if not successful
1 if successful
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 09, 2002 11:10 AM
To: [EMAIL PROTECTED]
Subject: RE: How do I tell the Win32/Win2K OS to activate
newly-setenvironment variables?
Peter Stucki writes:
> ***A T T E N T I O N***********************************************
> This email originates from the Internet and therefore may not
> be from the apparent sender.
>
> If you have any doubts about the origin or content of the email
please
> contact PC Support on x2288.
>
***********************************************************************
>
> Hi all,
> I have used the TieRegistry module to add new environment variables.
The environment vars appear just fine. The problem is that these
newly-set environment variables become active only after a re-boot, or
re-logon.
>
> Is there a way to avoid a re-boot or re-logon to immediately activate
the newly-set environment variables?
Depends what you mean. If you want the new environment variables to
be visible in a new process, then I have found that after setting
environment variables in the registry, a new command shell has the
new settings. No reboot is necessary.
If you want the new settings to be visible in the current process or
sub-processes that you are about to start, then you should set the
current process environment directly (i.e. $ENV{...} = ) rather than
use the registry.
If you mean that you want processes that are already running to see
the new settings, then I don't think that there is any way to do that
without at least restarting those processes.
HTH
--
Brian Raven
echo "ICK, NOTHING WORKED!!! You may have to diddle the includes.";;
-- Larry Wall in Configure from the perl distribution
-----------------------------------------------------------------------
The information contained in this e-mail is confidential and solely
for the intended addressee(s). Unauthorised reproduction, disclosure,
modification, and/or distribution of this email may be unlawful. If you
have received this email in error, please notify the sender immediately
and delete it from your system. The views expressed in this message
do not necessarily reflect those of
LIFFE Holdings Plc or any of its subsidiary companies.
-----------------------------------------------------------------------
_______________________________________________
ActivePerl mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
_______________________________________________
ActivePerl mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
