Is there a way to call the system path if the path has been changed in the current terminal? i.e.:
$env:Path = "C:\some new path"
#some coding that requires a different path set up
$env:Path = $defaultPath #would have to define $defaultPath by calling the system default path
Use the following to reload the $env:PATH environment variable from the registry, as future sessions would see it (assuming no further relevant registry updates are made).
If your current session hasn't made any relevant registry updates, this is the same as getting the value that was in effect on session startup - barring any dynamic additions via a $PROFILE script:
$env:PATH = [Environment]::GetEnvironmentVariable('Path', 'Machine'),
[Environment]::GetEnvironmentVariable('Path', 'User') -join ';'
Note:
A process' effective $env:PATH value is a composite value of a machine-level and a user-level registry entry, with the machine-level definition taking precedence, as reflected in the two .NET API calls above.
Note that the underlying registry locations - HKEY_LOCAL_MACHIN\System\CurrentControlSet\Control\Session Manager\Environment and HKEY_CURRENT_USER\Environment - are REG_EXPAND_SZ registry values, i.e. they may be defined in terms of other environment variables, such as %SystemRoot% and %ProgramFiles%.
Both the .NET API calls above - using [Environment]::GetEnvironmentVariable() - and PowerShell's Get-ItemProperty and Get-ItemPropertyValue cmdlets expand (interpolate) such references and return verbatim paths - which is what new processes see by default too.
Given the above, the only way to robustly retrieve the value that was in effect at session startup time is to save it in a variable at startup time.
It's still stored in the registry so you can just query it:
Located: HKLM:\System\CurrentControlSet\Control\Session Manager\Environment
$key = "HKCU:\Environment",
"HKLM:\System\CurrentControlSet\Control\Session Manager\Environment"
(Get-ItemPropertyValue -Path $key -Name Path) -Join ';'
Querying the key using Get-ItemPropertyValue (as suggested by Mklement) will give you just the property's value.
Related
I want unnatended install of rust, so I did this little script:
Write-Host "Installing Rust..." -ForegroundColor Cyan
$exePath = "$env:TEMP\rustup-init.exe"
Write-Host "Downloading..."
(New-Object Net.WebClient).DownloadFile('https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe', $exePath)
Write-Host "Installing..."
cmd /c start /wait $exePath -y
Remove-Item $exePath
$addPath = "$env:USERPROFILE\.cargo\bin"
[Environment]::SetEnvironmentVariable('PATH', $env:PATH, $addPath)
but I get
virtualbox-iso: Cannot convert argument "target", with value: "C:\Users\vagrant\.cargo\bin", for "SetEnvironmentVariable" to type
virtualbox-iso: "System.EnvironmentVariableTarget": "Cannot convert value "C:\Users\vagrant\.cargo\bin" to type
virtualbox-iso: "System.EnvironmentVariableTarget". Error: "Unable to match the identifier name C:\Users\vagrant\.cargo\bin to a valid
it looks like a text cannot be converted to a PATH type? What does it mean?
The immediate solution to your problem is that you need to call [Environment]::SetEnvironmentVariable() as follows:
# Modify the user-level PATH definition.
# To modify the machine-level definition, use 'Machine' instead of user 'User',
# but you then need to run with ELEVATION (as admin).
# !! SEE CAVEATS BELOW.
[Environment]::SetEnvironmentVariable('PATH', ($env:PATH + ";$addPath"), 'User')
That is, as Herohtar points out, the method expects only a complete, new value, as the second parameter, and its third parameter specifies the target scope for the persistent, registry-based environment-variable definition.
Caveats:
The process-level $env:PATH value is a composite value of the machine-level and user-level definitions in the registry, so with the command above you're in effect duplicating entries from the respective other scope.
Additionally, redefining the variable this way replaces any entries in the value that are defined in terms of other environment variables with the expanded, literal values.
$env:PATH contains expanded values to begin with, but even reading the unexpanded value directly from the registry won't work, because [Environment]::SetEnvironmentVariable() invariably writes the given string as a REG_SZ value (literal string) rather than as an REG_EXPAND_SZ value (string that may contain %FOO%-style references to other environment variables). Similarly, [Environment]::GetEnvironmentVariable() only reports expanded values.
A proper solution requires quite a bit of extra work, as discussed in this answer, which contains helper function Add-Path.
A pragmatic shortcut - if you're willing to accept that your registry definitions are converted to literal strings - is the following:
Read the current definition - for the target scope only - from the registry, via [Environment]::GetEnvironmentVariable()
Add to this scope-specific value and save it back to the same scope.
Additionally, you may want to add the new entry to the in-process definition of $env:PATH so that the change takes immediate effect.
Here is the solution in the context of a streamlined version of your code:
Write-Host "Installing Rust..." -ForegroundColor Cyan
$exePath = "$env:TEMP\rustup-init.exe"
Write-Host "Downloading..."
Invoke-WebRequest 'https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-init.exe' -OutFile $exePath
Write-Host "Installing..."
& $exePath -y
Remove-Item $exePath
$addPath = "$env:USERPROFILE\.cargo\bin"
$scope = 'User' # Change to 'Machine', if needed, which then requires ELEVATION.
[Environment]::SetEnvironmentVariable(
'PATH',
([Environment]::GetEnvironmentVariable('PATH', $scope) + ";$addPath"),
$scope
)
# Also update the current process' definition
$env:PATH += ";$addPath"
Iam trying to add a directory permanently to Path via CMD. When i try to use the command:
setx path "%path%;C:\Program Files (x86)\chromedriver\chromedriver.exe"
it only saves it to the uservariables Path. Is there a way to add it to the systemvariables Path by using CMD?
This is PowerShell code. There is probably some way to do it with a cmd-only reg.exe, but I have not been down that path. If you are on a supported Windows system, PowerShell will be available.
To do this, you will want to retrieve the current variable values before interpolation (resolving). To do that for the user PATH variable:
(Get-Item -Path 'HKCU:\Environment').GetValue(
'PATH', # the registry-value name
$null, # the default value to return if no such value exists.
'DoNotExpandEnvironmentNames' # the option that suppresses expansion
)
To get the system PATH variable:
(Get-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment').GetValue(
'PATH', # the registry-value name
$null, # the default value to return if no such value exists.
'DoNotExpandEnvironmentNames' # the option that suppresses expansion
)
Once you have the current, pre-interpolation PATH variable value, it can be changed before using Set-Item or setx.exe. Setting the system path will probably require Administrator permission, or should.
I followed this procedure in order to permanently add a path to SumatraPDF using powershell. The last few commands from the link are meant to check that the path has indeed been added.
When I access the path using the following command,
(get-itemproperty -path 'Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' -Name PATH).Path.split(';')
the result includes the path to SumatraPDF
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Windows\System32\OpenSSH\
C:\ProgramData\chocolatey\bin
C:\texlive\2021\bin\win32
C:\Users\921479\AppData\Local\SumatraPDF
However when I access it using the following command,
($env:path).split(';')
the result does not contain the path to SumatraPDF:
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0\
C:\Windows\System32\OpenSSH\
C:\ProgramData\chocolatey\bin
C:\texlive\2021\bin\win32
C:\Users\921479\AppData\Local\Microsoft\WindowsApps
Finally, actually passing sumatrapdf does not works, which indicates to me that the real path is the one accessed using the get-itemproperty command.
Why does the path set in the registry not correspond to the one set in $env:path? Is there a mistake in the procedure shown in the link I followed? How can I correct it?
I should mention I have already tried restarting the shell but it doesn't help.
Note:
See the middle section for helper function Add-Path
See the bottom section for why use of setx.exe should be avoided for updating the Path environment variable.
The procedure in the linked blog post is effective in principle, but is missing a crucial piece of information / additional step:
If you modify environment variables directly via the registry - which, unfortunately, is the right way to do it for REG_EXPAND_SZ-based environment variables such as Path - you need to broadcast a WM_SETTINGCHANGE message so that the Windows (GUI) shell (and its components, File Explorer, the taskbar, the desktop, the Start Menu, all provided via explorer.exe processes) is notified of the environment change and reloads its environment variables from the registry. Applications launched afterwards then inherit the updated environment.
If this message is not sent, future PowerShell sessions (and other applications) won't see the modification until the next logon / reboot.
Unfortunately, there's no direct way to do this from PowerShell, but there are workarounds:
Brute-force workaround - simple, but visually disruptive and closes all open File Explorer windows:
# Kills all explorer.exe processes, which restarts the Windows shell
# components, forcing a reload of the environment from the registry.
Stop-Process -Name explorer
Workaround via .NET APIs:
# Create a random name assumed to be unique
$dummyName = [guid]::NewGuid().ToString()
# Set an environment variable by that name, which makes .NET
# send a WM_SETTINGCHANGE broadcast
[Environment]::SetEnvironmentVariable($dummyName, 'foo', 'User')
# Now that the dummy variable has served its purpose, remove it again.
# (This will trigger another broadcast, but its performance impact is negligible.)
[Environment]::SetEnvironmentVariable($dummyName, [NullString]::value, 'User')
Workaround by calling the Windows API via an ad hoc-compiled P/Invoke call to SendMessageTimeout() in C#, via Add-Type:
While this is a proper solution, it invariably incurs a noticeable performance penalty due to the ad hoc-compilation the first time it is run in a session.
For details, see this blog post.
The approach in the blog post has another problematic aspect:
It retrieves the expanded environment-variable value from the registry, because that is what Get-ItemProperty and Get-ItemPropertyValue invariably do. That is, if directories in the value are defined in terms of other environment variables (e.g., %SystemRoot% or %JAVADIR%), the returned value no longer contains these variables, but their current values. See the bottom section for why this can be problematic.
The helper function discussed in the next section addresses all issues, while also ensuring that the modification takes effect for the current session too.
The following Add-Path helper function:
Adds (appends) a given, single directory path to the persistent user-level Path environment variable by default; use -Scope Machine to target the machine-level definition, which requires elevation (run as admin).
If the directory is already present in the target variable, no action is taken.
The relevant registry value is updated, which preserves its REG_EXPAND_SZ data type, based on the existing unexpanded value - that is, references to other environment variables are preserved as such (e.g., %SystemRoot%), and may also be used in the new entry being added.
Triggers a WM_SETTINGCHANGE message broadcast to inform the Windows shell of the change.
Also updates the current session's $env:Path variable value.
Note: By definition (due to use of the registry), this function is Windows-only.
With the function below defined, your desired Path addition could be performed as follows, modifying the current user's persistent Path definition:
Add-Path C:\Users\921479\AppData\Local\SumatraPDF
If you really want to update the machine-level definition (in the HKEY_LOCAL_MACHINE registry hive, which doesn't make sense with a user-specific path), add -Scope Machine, but not that you must then run with elevation (as admin).
Add-Path source code:
function Add-Path {
param(
[Parameter(Mandatory, Position=0)]
[string] $LiteralPath,
[ValidateSet('User', 'CurrentUser', 'Machine', 'LocalMachine')]
[string] $Scope
)
Set-StrictMode -Version 1; $ErrorActionPreference = 'Stop'
$isMachineLevel = $Scope -in 'Machine', 'LocalMachine'
if ($isMachineLevel -and -not $($ErrorActionPreference = 'Continue'; net session 2>$null)) { throw "You must run AS ADMIN to update the machine-level Path environment variable." }
$regPath = 'registry::' + ('HKEY_CURRENT_USER\Environment', 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment')[$isMachineLevel]
# Note the use of the .GetValue() method to ensure that the *unexpanded* value is returned.
$currDirs = (Get-Item -LiteralPath $regPath).GetValue('Path', '', 'DoNotExpandEnvironmentNames') -split ';' -ne ''
if ($LiteralPath -in $currDirs) {
Write-Verbose "Already present in the persistent $(('user', 'machine')[$isMachineLevel])-level Path: $LiteralPath"
return
}
$newValue = ($currDirs + $LiteralPath) -join ';'
# Update the registry.
Set-ItemProperty -Type ExpandString -LiteralPath $regPath Path $newValue
# Broadcast WM_SETTINGCHANGE to get the Windows shell to reload the
# updated environment, via a dummy [Environment]::SetEnvironmentVariable() operation.
$dummyName = [guid]::NewGuid().ToString()
[Environment]::SetEnvironmentVariable($dummyName, 'foo', 'User')
[Environment]::SetEnvironmentVariable($dummyName, [NullString]::value, 'User')
# Finally, also update the current session's `$env:Path` definition.
# Note: For simplicity, we always append to the in-process *composite* value,
# even though for a -Scope Machine update this isn't strictly the same.
$env:Path = ($env:Path -replace ';$') + ';' + $LiteralPath
Write-Verbose "`"$LiteralPath`" successfully appended to the persistent $(('user', 'machine')[$isMachineLevel])-level Path and also the current-process value."
}
The limitations of setx.exe and why it shouldn't be used to update the Path environment variable:
setx.exe has fundamental limitations that make it problematic, particularly for updating environment variables that are based on REG_EXPAND_SZ-typed registry values, such as Path:
Values are limited to 1024 characters, with additional ones getting truncated, albeit with a warning (as of at least Windows 10).
The environment variable that is (re)created is invariably of type REG_SZ, whereas Path is originally of type REG_EXPAND_SZ and contains directory paths based on other environment variables, such as %SystemRoot% and %JAVADIR%.
If the replacement value contains only literal paths (no environment-variable references) that may have no immediate ill effects, but, for an instance, an entry that originally depended on %JAVADIR% will stop working if the value of %JAVADIR% is later changed.
Additionally, if you base the updated value on the current session's $env:Path value, you'll end up duplicating entries, because the process-level $env:Path value is a composite of the machine-level and current-user-level values.
This increases the risk of running into the 1024-character limit, especially if the technique is used repeatedly. It also bears the risk of duplicate values lingering after the original entry is removed from the original scope.
While you can avoid this particular problem by retrieving the scope-specific value either directly from the registry or - invariably in expanded form - via [Environment]::GetEnvironmentVariable('Path', 'User') or [Environment]::GetEnvironmentVariable('Path', 'Machine'), that still doesn't solve the REG_EXPAND_SZ problem discussed above.
Use setx to permanently update an environment variable. Don't hack the registry.
After you invoke setx, just update the Path environment manually in the current session. Powershell: Reload the path in PowerShell
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
I found it is hard to keep my environment variables sync on different machines. I just want to export the settings from one computer and import to other ones.
I think it should be possible, but don't know how to do it. Can anyone help me? Thanks.
You can use RegEdit to export the following two keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
HKEY_CURRENT_USER\Environment
The first set are system/global environment variables; the second set are user-level variables. Edit as needed and then import the .reg files on the new machine.
I would use the SET command from the command prompt to export all the variables, rather than just PATH as recommended above.
C:\> SET >> allvariables.txt
To import the variablies, one can use a simple loop:
C:\> for /F %A in (allvariables.txt) do SET %A
To export user variables, open a command prompt and use regedit with /e
Example :
regedit /e "%userprofile%\Desktop\my_user_env_variables.reg" "HKEY_CURRENT_USER\Environment"
Combine #vincsilver and #jdigital's answers with some modifications,
export .reg to current directory
add date mark
code:
set TODAY=%DATE:~0,4%-%DATE:~5,2%-%DATE:~8,2%
regedit /e "%CD%\user_env_variables[%TODAY%].reg" "HKEY_CURRENT_USER\Environment"
regedit /e "%CD%\global_env_variables[%TODAY%].reg" "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
Output would like:
global_env_variables[2017-02-14].reg
user_env_variables[2017-02-14].reg
You can get access to the environment variables in either the command line or in the registry.
Command Line
If you want a specific environment variable, then just type the name of it (e.g. PATH), followed by a >, and the filename to write to. The following will dump the PATH environment variable to a file named path.txt.
C:\> PATH > path.txt
Registry Method
The Windows Registry holds all the environment variables, in different places depending on which set you are after. You can use the registry Import/Export commands to shift them into the other PC.
For System Variables:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
For User Variables:
HKEY_CURRENT_USER\Environment
My favorite method for doing this is to write it out as a batch script to combine both user variables and system variables into a single backup file like so, create an environment-backup.bat file and put in it:
#echo off
:: RegEdit can only export into a single file at a time, so create two temporary files.
regedit /e "%CD%\environment-backup1.reg" "HKEY_CURRENT_USER\Environment"
regedit /e "%CD%\environment-backup2.reg" "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
:: Concatenate into a single file and remove temporary files.
type "%CD%\environment-backup1.reg" "%CD%\environment-backup2.reg" > environment-backup.reg
del "%CD%\environment-backup1.reg"
del "%CD%\environment-backup2.reg"
This creates environment-backup.reg which you can use to re-import existing environment variables. This will add & override new variables, but not delete existing ones :)
Here is my PowerShell method
gci env:* | sort-object name | Where-Object {$_.Name -like "MyApp*"} | Foreach {"[System.Environment]::SetEnvironmentVariable('$($_.Name)', '$($_.Value)', 'Machine')"}
What it does
Scoops up all environment variables
Filters them
Emits the formatted PowerShell needed to recreate them on another machine (assumes all are set at machine level)
So after running this on the source machine, simply transfer output onto the target machine and execute (elevated prompt if setting at machine level)
A PowerShell script based on #Mithrl's answer
# export_env.ps1
$Date = Get-Date
$DateStr = '{0:dd-MM-yyyy}' -f $Date
mkdir -Force $PWD\env_exports | Out-Null
regedit /e "$PWD\env_exports\user_env_variables[$DateStr].reg" "HKEY_CURRENT_USER\Environment"
regedit /e "$PWD\env_exports\global_env_variables[$DateStr].reg" "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
Not being satisfied with answers from 12 years ago I've approached this a little differently. This approach could work with Win OS flavors older than Win 8 by using SET instead of SETX which is when SETX began being used.
NOTE:
Be sure to tune the RegEx for your preferred editor to achieve desired
results. For RegEx specific questions please seek help from various
sources including tutorials available from here. I'm using Sublime Text 4 for search and replace RegEx examples.
WARNING:
I would like to point out that following this process
blindly with copy and paste will most likely clobber existing settings
with the source data extracted. It DOES NOT merge the two sets of
data. That is your responsibility and I take no responsibility for
any damage that may result. Additionally, you should take time to
remove settings from the extracted env variables that pose issues or
no value such as changed paths and different hardware metrics such as
CPU core counts.
This approach avoids mixing System env variables with User env variables which a handful of previous answers are plagued with.
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment">>SystemEnvVariablesSourceMachine.txt
reg query "HKEY_CURRENT_USER\Environment">>UserEnvVariablesSourceMachine.txt
Clean up the files that were just created! Import success depends on this!
Use a RegEx capable editor and use the following search and replace:
NOTE: Some RegEx engines/tools require use of the $ character to
represent backreference in the Replace Pattern. If your not getting
the expected results in search and replace give that a try.
Search Pattern:
(?:\A\r?\n|^HKEY_CURRENT_USER\\Environment\r?\n?|^HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Environment\r?\n?|^\r?\n$|\r?\n\Z)
Replace Pattern (Literally Empty):
Literally Empty
and then
Search Pattern:
^\s+(.*?)\s{4}\w+\s{4}(.*?)$
Replace Pattern:
\1=\2
Its strongly advised you take a moment to do the same steps above on the destination machine using these file names:
SystemEnvVariablesDestinationMachine.txt
UserEnvVariablesDestinationMachine.txt
This also will serve as a backup for the upcoming import.
Once the DestinationMachine versions of the files are cleaned up its time to make a copy. Copy of each of the DestinationMachine files and name them something like:
SystemEnvVariablesFinalMerge.txt
UserEnvVariablesFinalMerge.txt
We're not done yet, that's just a version of the file you can feel safe to edit. Leave the DestinationMachine version of the files alone. Consider them a backup.
Next we will merge the SourceMachine files into the FinalMerge files. This provides a means to
manual review for cleanup of duplicates and bad data followed by a final output. There are plenty of ways
to do this, but the easiest way I've used is to prepare the data for comparison, then compare and merge, and then reassemble the data back
so that its importable.
Apply this search and replace RegEx pattern to each Source and FinalMerge file:
Search Pattern:
(^\w+=|.*?(?:;|$))
Replace Pattern:
\1\n
Then compare each Source to FinalMerge using a diff tool such as Beyond Compare 4, Meld, or Winmerge. My personal favorite is Beyond Compare 4. Keep in mind the data at this time may not be sorted
so you can take care at this time to sort the data taking care not to mix up variables from key to value structure. How to use those tools is out of scope here. Delete env variables that you do not wish to import at this time from the FinalMerge version of the file.
Once you're satisifed with the merge with cleanup applied save the changes in the FinalMerge files then restore the key to value mapping with the following RegEx pattern:
Search Pattern:
(.)$\r?\n
Replace Pattern:
\1
Then on the destination machine import the variables with powershell:
Get-Content .\UserEnvVariablesFinalMerge.txt | ForEach-Object {
$envVarDataSplit = $($_).split("=")
if($($envVarDataSplit).count -gt 0)
{
Write-Output "Key: $($envVarDataSplit[0]) ~ Value: $($envVarDataSplit[1])"
SETX $envVarDataSplit[0] "$($envVarDataSplit[1])"
}
}
NOTE:
Run powershell as administrator for this to succeed or you will
get an error.
Get-Content .\SystemEnvVariablesFinalMerge.txt | ForEach-Object {
$envVarDataSplit = $($_).split("=")
if($($envVarDataSplit).count -gt 0)
{
Write-Output "Key: $($envVarDataSplit[0]) ~ Value: $($envVarDataSplit[1])"
SETX $envVarDataSplit[0] "$($envVarDataSplit[1])" /M
}
}
NOTE:
If you encounter an error here its likely due to a need to
escape a character. You'll need to either manually enter that env
variable or figure out the proper escaped character sequence to get
around it.
If things have gone horribly wrong you should be able to revert to your DestinationMachine versions of the env variables using the previous command with the backup.