It's impossible to diagnose your problem without further information, but perhaps these troubleshooting tips help:
If you're invoking an external executable (sam) by name only, your problem must be that the directory in which the executable resides isn't listed in the $env:PATH environment variable defined for the current process.
However, it is possible that the external sam executable's directory isn't in $env:PATH and that sam is an auxiliary PowerShell command of the same name that knows the true sam's location and invokes it behind the scenes.
For instance an alias - such as New-Alias sam 'C:\path\to\sam.exe' - or a function - such as function sam { & C:\path\to\sam.exe $args } - could be defined.
From the PowerShell session where sam is found:
- To determine what type of command the name
sam refers to in your session, use the following and check the value of the CommandType column:
Get-Command sam
If the command type is Application, you are indeed dealing with an external executable, and the Source column will report its full path, from which you can glean the executable's directory path (which you can determine directly with Split-Path (Get-Command -Type Application sam).Path
- You then need to diagnose why that directory isn't in
$env:Path in the other session - see first section below.
If the command type isn't Application:
- You need to determine where the auxiliary alias or function is defined and why your other session doesn't see it, which, if the problem is reproducible in new sessions, must be connected to what profile files (as reflected in the automatic
$PROFILE variable) were loaded.
Diagnose why a directory is missing from $env:PATH:
Possible reasons:
You've just installed an executable, and the installer modified the persistent $env:PATH definition in the registry.
Something in your current PowerShell session has (possibly inadvertently) removed sam's directory from the in-process $env:PATH variable.
Solution:
- Refresh the in-process
$env:PATH definition from the registry with the following command (note that any prior in-process modifications are then lost):
$env:PATH = [Environment]::GetEnvironmentVariable('Path', 'Machine') + ';' + [Environment]::GetEnvironmentVariable('Path', 'User')
If these solutions don't help (persistently), the problem must be :
Either: Even the persistent Path variable definition is lacking an entry for the directory or interest (even though installers normally do add such an entry).
Or: The problem arises from what PowerShell profile files are loaded into the different environments.
For instance, if a given profile file adds a relevant $env:PATH entry dynamically to every session, a different environment, such as Visual Studio Code, may not load the same profile file.
See the next sections.
Add a directory entry to the persistent definition of the Path environment variable yourself:
If you don't know which directory to add to the Path variable, you can locate it via a command such as the following:
# Find the directory/ies on drive C: that contain a "sam.exe" file.
Get-ChildItem C:\ -Filter sam.exe -Recurse -File -ErrorAction Ignore |
ForEach-Object DirectoryName
Interactively:
Run sysdm.cpl, select the Advanced tab, and click on Environment Variables..., then modify the Path variable as desired.:
Note: To modify the Path variable under System variables, i.e. the system-wide part of the Path variable, you need to be an administrator.
After having modified Path this way, you need to open a new shell session in the manner described above in order to see the effects.
Programmatically:
- See this answer for helper function
Add-Path; the answer also explains why set.exe should not be used.
Diagnose what profile files were loaded into a session:
PowerShell's profile files are (by default) loaded (dot-sourced) on session startup and allow sessions to be customized, which can include things such as custom alias definitions, functions, and even in-process $env:PATH additions.
There are multiple profile files, all of which are loaded (by default), if present, along two independent dimensions: all-users vs. current-user, and all-hosts vs. current-host (a host being the PowerShell host environment, such as a regular console window or the terminal in Visual Studio Code).
The automatic $PROFILE variable reports the current-user, current-host profile-file path, but actually has normally invisible properties listing all paths (you can make them visible with $PROFILE | select * - see this answer).
What profiles are loaded into a session for a given user is determined by the following factors:
Fundamentally, whether profile loading is suppressed altogether, using the CLI's -NoProfile switch.
If not suppressed (the default, even with -Command and -File invocations):
What edition of PowerShell you're using: The comes-with Windows, legacy Windows PowerShell edition (whose latest and final version is 5.1), whose CLI is powershell.exe, vs. the install-on-demand cross-platform PowerShell (Core) edition, whose CLI is pwsh.exe, have separate profile locations.
The type of the host environment, as reflected in the automatic $Host variable.
To see what command line was used to invoke the current session, run the following:
[Environment]::CommandLine
Note:
- In the PIC (PowerShell Integrated Console) (which runs in Visual Studio Code's integrated terminal) you'll always see
-NoProfile among the parameters, but profiles may still be loaded during startup - see below.
It follows from the above that different host environments load different sets of profile files, and in the PIC (PowerShell Integrated Console) that comes with the PowerShell extension and which runs in Visual Studio Code's integrated terminal, different profile files are indeed loaded, IF enabled via the PowerShell: Enable Profile Loading setting - compared to regular console windows[1]
If you want your PIC sessions to load the same current-user profile as regular console windows:
Via Visual Studio Code's settings, first make sure that the PowerShell: Enable Profile Loading setting is enabled and start a new PIC session, if necessary.
From a PIC session, run psedit $PROFILE to open the host-specific current-user profile for editing.
Add the following content:
. ($PROFILE -replace '\.VSCode', '.PowerShell')
[1] Note that you can use PowerShell in the Visual Studio Code terminal even without the PowerShell extension, as a general-purpose shell, and such session do use the same profiles as regular console windows - see this answer.
