PATH update for tool installation using package managers like WinGet and Chocolatey
#391
Conversation
| - WT team didn't consider the need to install something and use it immediately with `cmd /c`. | ||
| - WT team support this feature only in interactive session, which `cmd /c` is not. | ||
|
|
||
| - **[PS REVIEW COMMENT]** We prefer to having this feature enabled consistently in PS. |
There was a problem hiding this comment.
As long as this feature of CMD only works in an interactive session, they don't need to worry about conflicts between sessions at all, since there is usually only one interactive session (excluding the terminal server). The situation is different with PowerShell, where the likelihood of conflicts is much higher since the field of use is unlimited and endless.. It might be worth analyzing this more deeply.
| > - unlike PowerShell, CMD isn't designed to be driven so easily from another application. | ||
| > - we chose to err on the side of caution with this design and used "stdin a console" to detect whether the session was truly single-user-direct-to-cmd-interactive. | ||
|
|
||
| - **[PS REVIEW COMMENT]** We prefer to having this feature enabled consistently in PS. |
There was a problem hiding this comment.
To continue my previous comment. To eliminate conflicts at the same level as CMD, this feature could be opt-out by default. Then host applications could include it explicitly if necessary, and pwsh only if STDIN is console.
This will reduce the difference from CMD and make it easier to follow WT team if they make changes to this feature.
|
|
||
| - Would it be reasonable to disable the feature in PowerShell but not in CMD? | ||
| - [dongbow] IMHO, it should be OK for us to honor this key too. | ||
| It seems not reasonable to have a separate way to disable this feature in PowerShell while keeping the feature on in CMD. |
There was a problem hiding this comment.
The reason may be that I pointed out in the first comment, and then it makes sense to think about the disabling in pwsh. If we follow the path that I indicated in my second comment, then this is not necessary.
|
|
||
| - **[PS REVIEW COMMENT]** No, the feature is only for the native command processor. | ||
|
|
||
| - **_[WT comments]_** CMD only covers EXE, but `scoop` is a `.ps1` or `.bat` file, so CMD doesn't see it. PowerShell may want to broaden your support to account for any command. |
There was a problem hiding this comment.
Only EXE? There is above:
Batch files run from an interactive shell will detect package managers as well,
and this is going to help things likeinstall_all_my_packages.bat.
So pwsh should follow this too. Although perhaps the only way to make it simple is to specify these bat files in the registry.
|
|
||
| ## Solution in CMD | ||
|
|
||
| CMD suffered with the same problem and the Windows Terminal team already [made a fix](https://microsoft.visualstudio.com/OS/_git/os.2020/pullrequest/10131240) |
| > | ||
| > 1. We will only detect changes to the BEGINNING or END of either `PATH` (user/system). | ||
| > 2. We will only ever **append** to CMD's current `PATH`. | ||
| > 3. This feature can be disabled by removing the list of package managers at `HKLM\SOFTWARE\Microsoft\Command Processor\KnownPackageManagers`. |
There was a problem hiding this comment.
Have you asked WT team why they need to have this list? Why not update the PATH every time (it's not that expensive)?
On Windows, when a user installs a tool using a package manager like WinGet or Chocolatey in PowerShell, the tool is often added to the system or user PATH environment variable. However, changes to PATH made during the installation process are not automatically propagated to running PowerShell sessions or other active console applications. As a result, users frequently need to
start a new PowerShell session to recognize and use the newly installed command-line tools.
This behavior can be confusing and disrupts the workflow—especially in automation scenarios or when users expect tools to be immediately available post-installation. Addressing this limitation would improve usability, align with user expectations, and reduce friction in both interactive and scripted environments.