Set a persistent environment variable from cmd.exe - windows

I have to set environment variables on different windows machines, but I don't want to be bothered changing them manually by getting on the properties screen of "My Computer"
I want to do it from the command line, with a batch file. As far as I understand, using set will only change the variable for the processes I will call in the command window.
I want to set it definitely, so later, when running a new process, it will use those new settings I have set. Is there a way to do that from the command line?

Use the SETX command (note the 'x' suffix) to set variables that persist after the cmd window has been closed.
For example, to set an env var "foo" with value of "bar":
setx foo bar /m
Though it's worth reading the 'notes' that are displayed if you print the usage (setx /?), in particular:
On a local system, variables created or modified by this tool will be available in future command windows but not in the current CMD.exe command window.
On a remote system, variables created or modified by this tool will be available at the next logon session.
In PowerShell, the [Environment]::SetEnvironmentVariable command.

The MSDN documentation for environment variables tells you what to do:
To programmatically add or modify system environment variables, add them to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment registry key, then broadcast a WM_SETTINGCHANGE message with lParam set to the string "Environment". This allows applications, such as the shell, to pick up your updates.
You will of course need admin rights to do this. I know of no way to broadcast a windows message from Windows batch so you'll need to write a small program to do this.

:: Sets environment variables for both the current `cmd` window
:: and/or other applications going forward.
:: I call this file keyz.cmd to be able to just type `keyz` at the prompt
:: after changes because the word `keys` is already taken in Windows.
#echo off
:: set for the current window
set APCA_API_KEY_ID=key_id
set APCA_API_SECRET_KEY=secret_key
set APCA_API_BASE_URL=https://paper-api.alpaca.markets
:: setx also for other windows and processes going forward
setx APCA_API_KEY_ID %APCA_API_KEY_ID%
setx APCA_API_SECRET_KEY %APCA_API_SECRET_KEY%
setx APCA_API_BASE_URL %APCA_API_BASE_URL%
:: Displaying what was just set.
set apca
:: Or for copy/paste manually ...
:: setx APCA_API_KEY_ID 'key_id'
:: setx APCA_API_SECRET_KEY 'secret_key'
:: setx APCA_API_BASE_URL 'https://paper-api.alpaca.markets'

Indeed SET TEST_VARIABLE=value works for current process only, so SETX is required. A quick example for permanently storing an environment variable at user level.
In cmd, SETX TEST_VARIABLE etc. Not applied yet (echo %TEST_VARIABLE% shows %TEST_VARIABLE%,
Quick check: open cmd, echo %TEST_VARIABLE% shows etc.
GUI check: System Properties -> Advanced -> Environment variables -> User variables for -> you should see Varible TEST_VARIABLE with value etc.

An example with VBScript (.vbs)
Sub sety(wsh, action, typey, vary, value)
Dim wu
Set wu = wsh.Environment(typey)
wui = wu.Item(vary)
Select Case action
Case "ls"
WScript.Echo wui
Case "del"
On Error Resume Next
wu.remove(vary)
On Error Goto 0
Case "set"
wu.Item(vary) = value
Case "add"
If wui = "" Then
wu.Item(vary) = value
ElseIf InStr(UCase(";" & wui & ";"), UCase(";" & value & ";")) = 0 Then
wu.Item(vary) = value & ";" & wui
End If
Case Else
WScript.Echo "Bad action"
End Select
End Sub
Dim wsh, args
Set wsh = WScript.CreateObject("WScript.Shell")
Set args = WScript.Arguments
Select Case WScript.Arguments.Length
Case 3
value = ""
Case 4
value = args(3)
Case Else
WScript.Echo "Arguments - 0: ls,del,set,add; 1: user,system, 2: variable; 3: value"
value = "```"
End Select
If Not value = "```" Then
' 0: ls,del,set,add; 1: user,system, 2: variable; 3: value
sety wsh, args(0), args(1), UCase(args(2)), value
End If

Related

Sending Mail through vbscript and attaching file using right click context menu mail not being send [duplicate]

I have this script saved in "test.vbs":
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(workFolder &"\test.txt", 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
When I run the script I want to pass the value of the "workFolder" variable.
How can I do this? Can I do it? Something like "cscript test.vbs workFolder:'C:\temp\'" perhaps?
Bonus question: Is it neccessary to clean up the passed variable with "Set workFolder = Nothing" or does VBSCript do that automatically when it terminates? Maybe "Set File = Nothing" and "Set FSO = Nothing" is unneccessary also? Please let me know if you know the answer to both these questions.
You can use WScript.Arguments to access the arguments passed to your script.
Calling the script:
cscript.exe test.vbs "C:\temp\"
Inside your script:
Set File = FSO.OpenTextFile(WScript.Arguments(0) &"\test.txt", 2, True)
Don't forget to check if there actually has been an argument passed to your script. You can do so by checking the Count property:
if WScript.Arguments.Count = 0 then
WScript.Echo "Missing parameters"
end if
If your script is over after you close the file then there is no need to set the variables to Nothing. The resources will be cleaned up automatically when the cscript.exe process terminates. Setting a variable to Nothing usually is only necessary if you explicitly want to free resources during the execution of your script. In that case, you would set variables which contain a reference to a COM object to Nothing, which would release the COM object before your script terminates. This is just a short answer to your bonus question, you will find more information in these related questions:
Is there a need to set Objects to Nothing inside VBA Functions
When must I set a variable to “Nothing” in VB6?
Inside of VBS you can access parameters with
Wscript.Arguments(0)
Wscript.Arguments(1)
and so on. The number of parameter:
Wscript.Arguments.Count
Each argument passed via command line can be accessed with: Wscript.Arguments.Item(0) Where the zero is the argument number: ie, 0, 1, 2, 3 etc.
So in your code you could have:
strFolder = Wscript.Arguments.Item(0)
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(strFolder, 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
Using wscript.arguments.count, you can error trap in case someone doesn't enter the proper value, etc.
MS Technet examples
You can also use named arguments which are optional and can be given in any order.
Set namedArguments = WScript.Arguments.Named
Here's a little helper function:
Function GetNamedArgument(ByVal argumentName, ByVal defaultValue)
If WScript.Arguments.Named.Exists(argumentName) Then
GetNamedArgument = WScript.Arguments.Named.Item(argumentName)
Else
GetNamedArgument = defaultValue
End If
End Function
Example VBS:
'[test.vbs]
testArg = GetNamedArgument("testArg", "-unknown-")
wscript.Echo now &": "& testArg
Example Usage:
test.vbs /testArg:123
To answer your bonus question, the general answer is no, you don't need to set variables to "Nothing" in short .VBS scripts like yours, that get called by Wscript or Cscript.
The reason you might do this in the middle of a longer script is to release memory back to the operating system that VB would otherwise have been holding. These days when 8GB of RAM is typical and 16GB+ relatively common, this is unlikely to produce any measurable impact, even on a huge script that has several megabytes in a single variable. At this point it's kind of a hold-over from the days where you might have been working in 1MB or 2MB of RAM.
You're correct, the moment your .VBS script completes, all of your variables get destroyed and the memory is reclaimed anyway. Setting variables to "Nothing" simply speeds up that process, and allows you to do it in the middle of a script.

Dynamically opening a website with VB script based on the website's IP address [duplicate]

I have this script saved in "test.vbs":
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(workFolder &"\test.txt", 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
When I run the script I want to pass the value of the "workFolder" variable.
How can I do this? Can I do it? Something like "cscript test.vbs workFolder:'C:\temp\'" perhaps?
Bonus question: Is it neccessary to clean up the passed variable with "Set workFolder = Nothing" or does VBSCript do that automatically when it terminates? Maybe "Set File = Nothing" and "Set FSO = Nothing" is unneccessary also? Please let me know if you know the answer to both these questions.
You can use WScript.Arguments to access the arguments passed to your script.
Calling the script:
cscript.exe test.vbs "C:\temp\"
Inside your script:
Set File = FSO.OpenTextFile(WScript.Arguments(0) &"\test.txt", 2, True)
Don't forget to check if there actually has been an argument passed to your script. You can do so by checking the Count property:
if WScript.Arguments.Count = 0 then
WScript.Echo "Missing parameters"
end if
If your script is over after you close the file then there is no need to set the variables to Nothing. The resources will be cleaned up automatically when the cscript.exe process terminates. Setting a variable to Nothing usually is only necessary if you explicitly want to free resources during the execution of your script. In that case, you would set variables which contain a reference to a COM object to Nothing, which would release the COM object before your script terminates. This is just a short answer to your bonus question, you will find more information in these related questions:
Is there a need to set Objects to Nothing inside VBA Functions
When must I set a variable to “Nothing” in VB6?
Inside of VBS you can access parameters with
Wscript.Arguments(0)
Wscript.Arguments(1)
and so on. The number of parameter:
Wscript.Arguments.Count
Each argument passed via command line can be accessed with: Wscript.Arguments.Item(0) Where the zero is the argument number: ie, 0, 1, 2, 3 etc.
So in your code you could have:
strFolder = Wscript.Arguments.Item(0)
Set FSO = CreateObject("Scripting.FileSystemObject")
Set File = FSO.OpenTextFile(strFolder, 2, True)
File.Write "testing"
File.Close
Set File = Nothing
Set FSO = Nothing
Set workFolder = Nothing
Using wscript.arguments.count, you can error trap in case someone doesn't enter the proper value, etc.
MS Technet examples
You can also use named arguments which are optional and can be given in any order.
Set namedArguments = WScript.Arguments.Named
Here's a little helper function:
Function GetNamedArgument(ByVal argumentName, ByVal defaultValue)
If WScript.Arguments.Named.Exists(argumentName) Then
GetNamedArgument = WScript.Arguments.Named.Item(argumentName)
Else
GetNamedArgument = defaultValue
End If
End Function
Example VBS:
'[test.vbs]
testArg = GetNamedArgument("testArg", "-unknown-")
wscript.Echo now &": "& testArg
Example Usage:
test.vbs /testArg:123
To answer your bonus question, the general answer is no, you don't need to set variables to "Nothing" in short .VBS scripts like yours, that get called by Wscript or Cscript.
The reason you might do this in the middle of a longer script is to release memory back to the operating system that VB would otherwise have been holding. These days when 8GB of RAM is typical and 16GB+ relatively common, this is unlikely to produce any measurable impact, even on a huge script that has several megabytes in a single variable. At this point it's kind of a hold-over from the days where you might have been working in 1MB or 2MB of RAM.
You're correct, the moment your .VBS script completes, all of your variables get destroyed and the memory is reclaimed anyway. Setting variables to "Nothing" simply speeds up that process, and allows you to do it in the middle of a script.

How to call VBScript from cmd.exe *and* pass parameters

I have a VBScript that I want to launch by dragging and dropping files onto a shortcut to it. At the moment the script does nothing except report how many parameters it receives and echo the first.
If I define the shortcut as:
"C:\Users\me\Documents\working\my_script.vbs" "param 1"
then, upon launch, it tells me I have one parameter and it is "param 1" exactly as you would expect. However, if I drag and drop a file onto the shortcut, I still only get one parameter and that is the path to the dropped file.
How do I get two parameters (whatever is coded into the link) and the drag-drop filename?
Change your shortcut properties, and instead of directly link to the .vbs file, use
WScript.exe "C:\Users\me\Documents\working\my_script.vbs" "param 1"
Now, the correct number of arguments is retrieved
Here is my args loop:
Set oArgs = Wscript.Arguments
Dim aArgs()
ReDim aArgs(oArgs.Count)
x = 0
Do Until x = oArgs.Count
aArgs(x) = oArgs(x)
x=x+1
Loop
Now you can reference your arguments by doing something like this:
Wscript.Echo aArgs(0)

SETX doesn't append path to system path variable

I have tried below command to append some path to system path variable by batch-file :
setx PATH "%PATH%;C:\Program Files\MySQL\MySQL Server 5.5\bin"
I have checked system variable path after running above batch-file, above path isn't in there.
You can see all windows Variable value content in below :
C:\Program Files (x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMDAPP\bin\x86;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\ProgramFiles (x86)\ATI Technologies\ATI.ACE\Core-Static;
What am i doing wrong?
To piggy-back on #Endoro's answer (I lack the rep to comment):
If you want to change the system-wide environment variables, you have to use /M, a la:
setx PATH "%PATH%;C:\Program Files\MySQL\MySQL Server 5.5\bin" /M
setx.exe is picky about placement of the /M, BTW. It needs to be at the end.
WARNING!
setx will truncate the value to 1024 characters.
If you use it to modify PATH you might mess up your system.
You can use this PowerShell snippet to add something to your path:
$new_entry = 'c:\blah'
$old_path = [Environment]::GetEnvironmentVariable('path', 'machine');
$new_path = $old_path + ';' + $new_entry
[Environment]::SetEnvironmentVariable('path', $new_path,'Machine');
In case you want to not re-add an already existing entry something like this will do (see for a better version further down):
$new_entry = 'c:\blah'
$search_pattern = ';' + $new_entry.Replace("\","\\")
$old_path = [Environment]::GetEnvironmentVariable('path', 'machine');
$replace_string = ''
$without_entry_path = $old_path -replace $search_pattern, $replace_string
$new_path = $without_entry_path + ';' + $new_entry
[Environment]::SetEnvironmentVariable('path', $new_path,'Machine');
Here a newer version that I'm using now (2017-10-23).
This version handles nested paths correctly.
E.g. it handles the case of PATH containing "c:\tool\foo" and you want to add "c:\tool".
Note, that this expands values that are in path and saves them back expanded.
If you want to avoid this, have a look at the comment of #ErykSun below.
$desired_entry = 'C:\test'
$old_path = [Environment]::GetEnvironmentVariable('path', 'machine');
$old_path_entry_list = ($old_path).split(";")
$new_path_entry_list = new-object system.collections.arraylist
foreach($old_path_entry in $old_path_entry_list) {
if($old_path_entry -eq $desired_entry){
# ignore old entry
}else{
[void]$new_path_entry_list.Add($old_path_entry)
}
}
[void]$new_path_entry_list.Add($desired_entry)
$new_path = $new_path_entry_list -Join ";"
[Environment]::SetEnvironmentVariable('path', $new_path,'Machine');
you shouldn't look at the system environment variables but to your user environment variables:
Should never use setx for a path since it's limited to 1024 chars, as mentioned.
Could use reg add:
set pathkey="HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment"
for /F "usebackq skip=2 tokens=2*" %%A IN (`reg query %pathkey% /v Path`) do (reg add %pathkey% /f /v Path /t REG_SZ /d "%%B;C:\Program Files\MySQL\MySQL Server 5.5\bin")
or set pathkey="HKEY_CURRENT_USER\Environment" for user path.
Then to broadcast the change:
powershell -command "& {$md=\"[DllImport(`\"user32.dll\"\",SetLastError=true,CharSet=CharSet.Auto)]public static extern IntPtr SendMessageTimeout(IntPtr hWnd,uint Msg,UIntPtr wParam,string lParam,uint fuFlags,uint uTimeout,out UIntPtr lpdwResult);\"; $sm=Add-Type -MemberDefinition $md -Name NativeMethods -Namespace Win32 -PassThru;$result=[uintptr]::zero;$sm::SendMessageTimeout(0xffff,0x001A,[uintptr]::Zero,\"Environment\",2,5000,[ref]$result)}"
SETX /M Path "%PATH%;%ProgramFiles%\MySQL\MySQL Server 5.5\bin\
It will append your path to system variable
To update and expand on Endoro's answer for Windows 10, manually add the path to your Path system variable as a new variable. I wasn't able to get setx to work even changing the flags around. Doing it manually was simple.
To get to your system environmental variables -> Windows Key -> Edit the system environmental variables -> Click Environmental Variables -> Select the Path variable in the System variables frame -> Click Edit -> Click New -> Add the path -> Click Okay
Make sure you close all your CLI windows and open a new one if you're trying to verify by checking the version.
Windows showing where to edit the Path environmental variable
I faced the same problem when I tried to add path variables related to fortran. (Eclipse for C/C++/Fortran)
I tried
SETX /M Path "%PATH%;C:\Users\mahidhai\cygwin64\bin"
in command prompt as administrator. I got a warning saying
data was truncated to 1024 characters and stored.
Edit registry via GUI
Run->regedit
Navigate to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
HKLM is short for HKEY_LOCAL_MACHINE
Doubleclick on the Path entry or invoke value edit mode via context menu
Append the parent directory of your exe separated by a semicolon ;
Refresh the registry changes to the system
No worries on editing the registry, it is safe as long as you don't change random values.
Though if using a GUI you should use the purpose built one.
Edit via purpose built GUI starting in Explorer
Right click on "This PC"
Click on "Properties"
On the left panel of the window that pops up, click on "Advanced System Settings"
Click on the "Advanced" tab
Click on "Environment Variables" button at the bottom of the window
Image from this answer

Get SYSTEM temp folder?

I'm looking for something similar to this question. However, I am looking specifically to dynamically find the location of the system's temp folder (i.e. the temp folder used by services.)
Is this possible?
Thanks,
Here you go (in VBS)
Set environmentVars = WScript.CreateObject("WScript.Shell").Environment("Process")
tempFolder = environmentVars("TEMP")
msgbox(tempFolder)
I'm not sure if your system will have an environment variable called "TEMP", so go to the command line and type
set
You'll get a list of environment vars, and their values. Pick the one that has your temp folder in it.
Set objShell = CreateObject("WScript.Shell")
Set colEnvironment = objShell.Environment("PROCESS")
objPath = colEnvironment("temp")
WScript.Echo objPath
In that case
Set objShell = CreateObject("WScript.Shell")
Set colEnvironment = objShell.Environment("PROCESS")
objPath = colEnvironment("windir")
WScript.Echo objPath & "\temp"
hope this will help
After researching a little into this, I believe there is no way to use environment variables to capture the location of another user's %TEMP% folder (in this case the System user).
The SYSTEM environment variables is stored in registry key: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment
The environment variables for users is stored in registry keys: HKEY_USERS[user SID]\Environment
In order to get the value of any environment variable (in particular TEMP), need to check the presence of this variable in the branch for specified the user. If it is there, then you can use it. If it is not there, then you need to take a value from the system registry branch.
In C#, its...
System.Collections.IDictionary Vars = System.Environment.GetEnvironmentVariables();
String TempPath = Vars["TEMP"];
You get an entire array of elements... Path, Temp, SessionName, PathExt, UserDomain, SystemDrive, WinDir, etc...
Maybe this may be of some use: System.IO.Path.GetTempPath()

Resources