#512 STAF never re-reads STAF/Env/Path

[Bryan Osenbach]

Problem: I want to update the system path without rebooting so every subsiquent call to an executable does not need the fully qualified path.

Case:
1. Install Perl
2. Manually update STAF/Env/Path with %PATH%;C:\Perl\bin
3. Attempt to execute perl -Version through STAF

Var list:

[root@wplcauto perl]# staf intel146 var resolve system string {STAF/Env/Path}
Response
--------
C:\STAF\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program Files\IBM\Director\bin;C:\Program Files\Common Files\IBM\ICC\cimom\bin;C:\Perl\bin

Perl executable attempt:

[root@wplcauto perl]# staf intel146 process start shell command perl parms -Version stderrtostdout returnstdout wait
Response
--------
{
Return Code: 1
Key : <None>
Files : [
{
Return Code: 0
Data : 'perl' is not recognized as an internal or external command,
operable program or batch file.

}
]
}

Using the ENV parameter to the STAF process element is not an option in this particular case.

Is there any way I can set the PATH variable and have STAF read it without rebooting?

[Sharon Lucas]

Logged In: YES
user_id=285070
Originator: NO

This is not a "bug". The STAF/Env/xxx variables show the environment in which STAFProc is running. Thus, their values never change while STAFProc is running, nor should you change the values of any STAF/Env/xxx or STAF/Config/xxx variable. It is very important that you understand that each process started via STAF runs in the same environment as STAFProc, and thus, with the same environment variables that were set when STAFProc was started.

In regards to is there "any way I can set the PATH variable and have STAF read it without rebooting?". Yes, you could restart STAFProc and then use the environment variables that exist in the terminal/command prompt where STAFProc is started. That is, no "rebooting" is necessary. Of course, if the PATH was changed by something (like a Perl install), you'll need to start a new terminal/command prompt to pick up the new environment variables, but that is not a "STAF" specific thing -- just how environment variables work on various operating systems.

STAF provides the ENV option on a PROCESS START request which allows you to specify environment variables that will be set for the process. I'm not sure why you don't think using the ENV option is an option. Why can't you do something like the following?

C:\&gt;STAF local PROCESS START SHELL COMMAND "perl -Version" ENV PATH=C:\Perl\bin;{STAF/Env/PATH} RETURNSTDOUT STDERRTOSTDOUT WAIT
Response
--------
{
Return Code: 0
Key : <None>
Files : [
{
Return Code: 0
Data : Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
... More data removed for brevity ...
}
]
}

[Bryan Osenbach]

Logged In: YES
user_id=1350649
Originator: YES

1. I can't use ENV because there are thousands of lines of process code that doesn't contain ENV statements and have always relied on the reboot. Any subsiquent call to perl will fail unless it includes ENV.
2. How do you suggest restarting STAF from STAF? The same environment variables will always be inherited from parent shell.

[Sharon Lucas]

Logged In: YES
user_id=285070
Originator: NO

2. I don't really have any suggestions on how to programatically do that. I was just trying to explain how STAF and environment variabless work.

[Bryan Osenbach]

Logged In: YES
user_id=1350649
Originator: YES

What's the purpose of having of STAF/Env/Path variable if I can't update it? Why should the variables never be updated?

[Sharon Lucas]

Logged In: YES
user_id=285070
Originator: NO

The purpose of the STAF/Env/xxx variables is to show you the environment in which STAFProc is running. Changing it's value does not really change the environment in which STAFProc is running.

Note that what I meant before is that you could restart STAFProc with the Perl environment variable set. To restart STAF from STAF you'd have to start a temporary instance of STAF (using a different port and STAF_INSTANCE_NAME) and then shutdown the original version of STAF, and wait for it to shutdown, and then restart STAFProc with with a PROCESS START request using the ENV option to add C:\Perl\bin; to the PATH and then shutdown the temporary instance of STAF. We do something like this to automatically upgrade STAF via a STAX job.

[Charles Rankin]

Logged In: YES
user_id=279901
Originator: NO

This is an interesting area to me. As you already know, STAF doesn't currently support changing its own environment variables. However, STAF could certainly be changed to allow this. The interesting question is whether it should be?

Bryan, I can definitely see where you are coming from. You don't really share the machine with anyone and you want to make an update that will (positively) affect all future processes that are executed. And, you want to do so without having to really "disturb" the setup as is.

Now, if the machine was shared across different people/teams/work efforts, etc., then I don't think I'd want someone to be able to modify the system environment of all future processes dynamically, as there is a reasonable chance that it could affect others (negatively).

I suppose that there could be some kind of new operational setting that indicated whether the environment can be dynamically changed or not. I'd normally have it set to off, but people could turn it on in the STAF.cfg. With something like that, it would at least seem feasible to implement this. I'd deem it more a feature than a bug, and I'm not sure how high it would get prioritized, but it at least seems doable.

While I can't seem to find it at the moment, there was a feature that formed the basis of how I'd do this. It had to do with "typing" the STAF variables, such that you could override their get/set methods. In this case, all the STAF/Env variables would be of a type where the set() would update the STAFProc environment. However, this would also enable other types of variables such as a time-of-day variable and a random number variable, etc. This is all just food for thought for would be implementers. :)

[Bryan Osenbach]

Logged In: YES
user_id=1350649
Originator: YES

Good idea for the STAF restart with the ENV. It's simple, effective, and will get me where I want to go. Coding the multiple instances is more of a pain than what it's worth though. I'd rather ship over a .bat file, execute it, use a timer element to break out of the process, and regain control on the other side.

[Eyal Teutsch]

I (Zend) would find reloading/setting ENV variable (PATH in particular) during runtime quite useful.
During our QA cycle, we install our product (Zend Server) via STAF.
Zend Server in turns adds some paths to Windows $PATH env variable - now we would like to reload/set $PATH back to STAF, without restarting STAF.