Generally speaking:
- PowerShell respects the entries in the
Path
environment variable the same way that cmd
does.
- These shells only differ with respect to executing executables located in the current directory (assuming it isn't listed in
Path
): cmd.exe
allows execution by name only (e.g., exercism
), whereas PowerShell, as a security feature, requires use of a path to explicitly signal the intent (e.g., .\exercism
)
- After having modified the persistent
Path
definitions in the registry, a new shell session has to be started via the Windows GUI shell (Start Menu, taskbar) to see the changes. When in doubt, log off and back on again, or reboot.
Your Path
value is misconfigured:
There should be no references to environment variables such as %EXERCISM%
in your in-session Path
value - neither cmd.exe
nor PowerShell will recognize such references in this context; they interpret the entries verbatim (in contexts where variable references are recognized, only cmd.exe
would recognize the syntax form %EXERCISM%
; the PowerShell equivalent would be $env:EXERCISM
)
In the registry, where the persistent environment-variable definitions are stored, you can base Path
entries on references to other environment variables (e.g, %SystemRoot%\System32
). The system itself ensures that (shell) processes see only the expanded forms of these variables. That is, what a process sees as the Path
variable value is normally a ;
separated list of verbatim paths (and is a concatenation of the machine-level and the user-level values).
This mechanism relies on the relevant registry Path
values - in keys HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment
(machine-level) and HKEY_CURRENT_USER\Environment
(user-level) - to be defined as REG_EXPAND_SZ
, which they are by default.
Your screenshot suggests that (at least) your user-level key has been converted to a static string value, REG_SZ
, which prevents the necessary expansion of environment-variable references.
This quiet corruption can easily happen if you use tools such as setx.exe
or even the .NET [Environment]::SetEnvironmentVariable()
API to update the persistent Path
values - see this answer.
The proper way to update the persistent Path
values is via direct registry access (which is unfortunate, given the complexity) - see this answer.
Fix:
Re-convert your persistent user-level Path
definition to value type REG_EXPAND_SZ
, as follows (works analogously for the machine-level definition, in which case elevation (run as admin) is required):
$regPath = 'registry::HKEY_CURRENT_USER\Environment'
Set-ItemProperty -Type ExpandString -LiteralPath $regPath Path (Get-ItemPropertyValue -LiteralPath $regPath Path)