| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Codacy is confused about the ternary operator, we should probably update the PSSA rule |
Sorry, something went wrong.
|
PoshChan-Bot (@PoshChan) please retry windows |
Sorry, something went wrong.
|
Steve Lee (@SteveL-MSFT), successfully started retry of PowerShell-CI-Windows |
Sorry, something went wrong.
…cs.cs Co-Authored-By: Ilya <darpa@yandex.ru>
…cs.cs Co-Authored-By: Dongbo Wang <dongbow@microsoft.com>
|
🎉v7.0.0-rc.1 has been released which incorporates this pull request.:tada: Handy links: |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
The problem is that Windows treats User scope env vars as the preferred value over Machine scope env vars. So if a user has PSModulePath defined in their User scope, then the Machine scope one isn't used. In other words, the Process scope env var is the same as the User scope env var. However, Windows treats PATH differently in that it concatenates PATH from User scope with PATH from Machine scope. PSModulePath works like PATH so it should also do the same thing that Windows doesn't automatically do. You can observe this with just cmd.exe.
The fix here is to start with env var inherited by Process. If it's the same as the one in User scope, it means the user hasn't modified it and it's incomplete, so we append the Machine scope one. If it's different, we just use the Process one.
Also fixed an issue where PSModulePath was a single path without a path separator.
PR Context
Fix #11172
PR Checklist