starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Opening terminal in directory doesn't expand path variable #16389

New Issue
Closed
opened 2026-01-31 05:06:09 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 05:06:09 +00:00
Owner
Copy Link

Originally created by @thakyZ on GitHub (Jan 13, 2022).

Windows Terminal version

1.11.3471.0

Windows build number

10.0.22000.0

Other Software

Windows Explorer

Steps to reproduce

  1. Open Regedit
  2. Go to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
  3. Add a REG_EXPAND_SZ named APROG_DIR and set it to a folder that will contain programs we want to add to path.
  4. Add another REG_EXPAND_SZ named APROG_FOLD add %APROG_DIR%\ffmpeg\bin or something equivalent for a program's path.
  5. Edit the Path variable and copy its contents, then delete it and add a new REG_EXPAND_SZ named Path and add the contents that you copied, and append ;%APROG_FOLD% .
  6. Then go and open Windows terminal from the start menu and make sure you can execute the program you added in APROG_FOLD make sure that $env:Path has all the path variables expanded.
  7. Then, if that works, go to a folder in your drive, right click and press Open in Windows Terminal and notice how you cannot execute the program you added to the path and that $env:Path doesn't have it's expended values.

Expected Behavior

The Path variable should be able to expand any environment value in any way it's opened.

Actual Behavior

However, it doesn't when opened from a directory's context menu.

Originally created by @thakyZ on GitHub (Jan 13, 2022). ### Windows Terminal version 1.11.3471.0 ### Windows build number 10.0.22000.0 ### Other Software Windows Explorer ### Steps to reproduce 1. Open Regedit 2. Go to `Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment` 3. Add a `REG_EXPAND_SZ` named `APROG_DIR` and set it to a folder that will contain programs we want to add to path. 4. Add another `REG_EXPAND_SZ` named `APROG_FOLD` add `%APROG_DIR%\ffmpeg\bin` or something equivalent for a program's path. 5. Edit the `Path` variable and copy its contents, then delete it and add a new `REG_EXPAND_SZ` named `Path` and add the contents that you copied, and append `;%APROG_FOLD%` . 6. Then go and open Windows terminal from the start menu and make sure you can execute the program you added in `APROG_FOLD` make sure that `$env:Path` has all the path variables expanded. 7. Then, if that works, go to a folder in your drive, right click and press `Open in Windows Terminal` and notice how you cannot execute the program you added to the path and that `$env:Path` doesn't have it's expended values. ### Expected Behavior The Path variable should be able to expand any environment value in any way it's opened. ### Actual Behavior However, it doesn't when opened from a directory's context menu.
claunia added the Resolution-Duplicate label 2026-01-31 05:06:09 +00:00
claunia commented 2026-01-31 05:06:11 +00:00
Author
Owner
Copy Link

@malxau commented on GitHub (Jan 13, 2022):

See #9741 . I think Eryk's comments there apply to what you're seeing - if expansion happens in arbitrary order, having multiple dependent REG_EXPAND_SZ values is not guaranteed to resolve correctly.

@malxau commented on GitHub (Jan 13, 2022): See #9741 . I think Eryk's comments there apply to what you're seeing - if expansion happens in arbitrary order, having multiple dependent REG_EXPAND_SZ values is not guaranteed to resolve correctly.
claunia commented 2026-01-31 05:06:11 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 13, 2022):

Yea, this sure sounds like /dup #9741 to me. We can continue the discussion there if necessary. Thanks!

@zadjii-msft commented on GitHub (Jan 13, 2022): Yea, this sure sounds like /dup #9741 to me. We can continue the discussion there if necessary. Thanks!
claunia commented 2026-01-31 05:06:11 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 13, 2022):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Jan 13, 2022): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
claunia commented 2026-01-31 05:06:11 +00:00
Author
Owner
Copy Link

@eryksun commented on GitHub (Jan 13, 2022):

You're assuming that the enumeration order of values in a key is the insertion order (e.g. deleting and reinserting "Path" inserts it after "APROG_FOLD"). However, the API makes no guarantee that RegEnumValueW() enumerates values in insertion order, or that the enumeration order is the same in all contexts, or that the order persists when the system is rebooted.

Since you're not doing anything to broadcast a WM_SETTINGCHANGE message, Explorer's environment never gets updated in your example. However, the shell extension that implements "Open in Windows Terminal" is hosted in an instance of dllhost.exe, which gets executed with an updated environment by a system service. The source of the updated environment is CreateEnvBlock() in profapi.dll, which is the internal implementation of CreateEnvironmentBlock().

Similarly, when executing Terminal from the start menu, it gets executed by a system service ("appinfo" in this case), which creates a new environment block via CreateEnvironmentBlock(). The appinfo service implements an additional fix for the new environment block. It sets its own values of windir, SystemDrive, and SystemRoot in the new environment, and then it calls RtlExpandEnvironmentStrings() to expand the entire block in a single call.

This can help in simple cases. In your example, if "Path" happens to be set in the environment before "APROG_DIR" and "APROG_FOLD", then PATH will contain the raw value "%APROG_FOLD%". If it happens that APROG_FOLD is expanded correctly in the environment, then the extra RtlExpandEnvironmentStrings() call will fix the value of PATH.

@eryksun commented on GitHub (Jan 13, 2022): You're assuming that the enumeration order of values in a key is the insertion order (e.g. deleting and reinserting "Path" inserts it after "APROG_FOLD"). However, the API makes no guarantee that [`RegEnumValueW()`](https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regenumvaluew) enumerates values in insertion order, or that the enumeration order is the same in all contexts, or that the order persists when the system is rebooted. Since you're not doing anything to broadcast a `WM_SETTINGCHANGE` message, Explorer's environment never gets updated in your example. However, the shell extension that implements "Open in Windows Terminal" is hosted in an instance of dllhost.exe, which gets executed with an updated environment by a system service. The source of the updated environment is `CreateEnvBlock()` in profapi.dll, which is the internal implementation of `CreateEnvironmentBlock()`. Similarly, when executing Terminal from the start menu, it gets executed by a system service ("appinfo" in this case), which creates a new environment block via `CreateEnvironmentBlock()`. The appinfo service implements an additional fix for the new environment block. It sets its own values of `windir`, `SystemDrive`, and `SystemRoot` in the new environment, and then it calls `RtlExpandEnvironmentStrings()` to expand the entire block in a single call. This can help in simple cases. In your example, if "Path" happens to be set in the environment before "APROG_DIR" and "APROG_FOLD", then `PATH` will contain the raw value "%APROG_FOLD%". If it happens that `APROG_FOLD` is expanded correctly in the environment, then the extra `RtlExpandEnvironmentStrings()` call will fix the value of `PATH`.
claunia commented 2026-01-31 05:06:11 +00:00
Author
Owner
Copy Link

@thakyZ commented on GitHub (Feb 9, 2022):

Well what ever caused it is no longer happening, and all the env variables resolve like they should, so I will close this. I don't know what happened to make it break other than a possible issue with windows upon an update.

@thakyZ commented on GitHub (Feb 9, 2022): Well what ever caused it is no longer happening, and all the env variables resolve like they should, so I will close this. I don't know what happened to make it break other than a possible issue with windows upon an update.
claunia commented 2026-01-31 05:06:12 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 9, 2022):

Thanks for closing the loop here!

@DHowett commented on GitHub (Feb 9, 2022): Thanks for closing the loop here!
claunia commented 2026-01-31 05:06:12 +00:00
Author
Owner
Copy Link

@malxau commented on GitHub (Feb 9, 2022):

I think the point is, environment expansion is one pass, so what happens depends on the order of variables in the block - as in, the outcome is random. While it's great that it happens to work today, it's likely to stop working randomly too. There's no guarantee that recursive expansion will resolve as expected.

@malxau commented on GitHub (Feb 9, 2022): I think the point is, environment expansion is one pass, so what happens depends on the order of variables in the block - as in, the outcome is random. While it's great that it happens to work today, it's likely to stop working randomly too. There's no guarantee that recursive expansion will resolve as expected.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#16389
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?