Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Environment Variables 1

Status
Not open for further replies.

SysAdmMke

Technical User
Jan 18, 2006
34
US

set oShell=createobject("WScript.Shell")
set envSystem = oshell.Environment("system")
var = "TEST"
envSystem.item(var) = 1234 'create the env variable

When I use the code above, my variable gets set under the environmental variables under my computer. This is good but I also want to see this variable with the dos set command.

That way if I echo %TEST% from the DOS command line, I should see 1234

Why doesn't the TEST variable show up under set?


Thanks
Mike
 
This works for me:
Code:
set oShell=createobject("WScript.Shell")
set envSystem = oshell.Environment("process")
var = "TEST" 
envSystem.item(var) = 1234 'create the env variable
oShell.Run "%COMSPEC% /K echo test=%test%", , True

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886
 
Thanks PHV

How come when I go to the DOS command prompt and type SET

It doesn't show up on the Environmental Variables List.

and if I echo %TEST% . Does this mean it is losing the variable when the script closes?

Thanks
Mike
 
it is losing the variable when the script closes
Sure.
You have to open the console from within the script as demonstrated in my post.

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886
 
>How come when I go to the DOS command prompt and type SET It doesn't show up on the Environmental Variables List.
That happens in win9x/me, if I recall. Winnt-series (or 2000+) should retain that variable if you open the cmd after the script being run; and you have to delete it if it is of no use but testing. What is your os?
 
Incorrect I'm afraid, tsuji.

Environment variables that you set this way are only valid for the process (and child processes of that process) that sets them; basically they are session environment variables.

System environment variables typically require that you be able to write to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment registry key, then broadcast a WM_SETTINGCHANGE message. But this is tricky from VBScript.

There is, however, a WMI hack (in the sense that it uses some undocumented methods) that can set system environment variables:

Code:
[blue]strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set objVariable = objWMIService.Get("Win32_Environment").SpawnInstance_

objVariable.Name = "Example"
objVariable.UserName = "<SYSTEM>"
objVariable.VariableValue = "This is an example"
objVariable.Put_[/blue]
 
Well, it is set to "system" in the op's script excerpt, and that's how the script would behave.
 
Apologies. You are correct. I wasn't paying proper attention
 
I know the wmi ramification maybe not as much as you know. I agree there is some dark point surrounding the issue, apart from the general broadcast of the change made to the running processes, it is the right to doing so. It is therefore safe to assume it needs the high privilege if not the highest for such thing to happen.
 
The one thing that still remains is to issue the WM_SETTINGCHANGE after creating the system environment variables (if we want them to be visible to the SET command). We can't do this directly in VBS, but we can indirectly via:

oShell.Run "%windir%\System32\RUNDLL32.EXE user32.dll,UpdatePerUserSystemParameters", 1, True
 
That's indeed what I am alluding to. But vbs won't be very apt to touch those corners of the edifice with comfort without stretching too much to be counted on reliably.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top