Repository navigation
Update installer to add "App Path" location for pwsh.exe #6046
Description
Steps to reproduce
Windows only. Attempting to start "pwsh.exe" (without the path included) using Task Scheduler results in a file not found error. The same with "Powershell.exe" works as expected.
Expected behavior
For pwsh.exe to run and perform the activities in the arguments, be that a file or whatever.
Actual behavior
See #5919
#5226 is also vaguely related.
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.1
PSEdition Core
GitCommitId v6.0.1
OS Microsoft Windows 10.0.16299
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Choosing to define the entire path isn't a solution, only a temporary workaround until the next release of PowerShell Core, then the folder name changes... 6.0.0 to 6.0.1 for example.
As per #5919, the resolution would seem to be to create an App Path entry for "pwsh.exe" as is in place for "Powershell.exe" already - presumably updated/maintained by the Windows installers.
Activity
bergmeister commentedon Jan 27, 2018
How are we going to handle side by side installation of 6.0 and 6.1 in the future? I guess the installer needs to have a checkbox to make adding to any sort of PATH or app path optional.
My proposal would be to have a global
pwsh.exesimilar todotnet.exethat then decided into which specific version to call into, which gets decided using e.g. a/versionparameter and/or something similar to aglobal.jsonthat contains the major and minor version to be used.lwsrbrts commentedon Jan 27, 2018
Ooh, tough one but I guess that also applies to the question "How would you handle that from the command line anyway?" - what is the approach for SxS when a user goes in to cmd.exe first and enters pwsh.exe but they have 6.0.x and 6.1.x installed?
I believe the default "App Path" version should always be the latest version to avoid confusion and frustration. If an older version overwrites the PATH or "App Path" just because it was installed afterward, there'll be mutiny.
Choice is the best option so a default checked "Set as default PowerShell Core version?" with a "What does this mean?" link or something to some documentation may be the best initial choice. In the documentation, it's spelled out that if they wish to schedule tasks using a specific version, they must specify the full path to the binary they want...however it results in the same problem I've had; if an SxS version of say 6.0.1 is upgraded to 6.0.2 and the "App Path" entry remains as pointing to 6.1.0, their scheduled tasks with the path to the 6.0.1 version break, as per #5919.
One for the community to give an opinion on as something tells me the cost of having a main entry "exe" which decides the version to use will cause other compatibility problems and have a cost. I like the idea of a switch in the binary but I've no idea how that would be handled in terms of dealing with looping, runtime, elevation.
robsonsobral commentedon Jan 27, 2018
The documentation says that:
But this is impossible with the installation path having version numbers. I just installed version 6.0.1 and broke my VSCode configuration.
iSazonov commentedon Jan 27, 2018
I like idea about AppPath.
I think we should move from %PATH% to AppPath. AppPath is for the quick launch of applications while %PATH% is intended to specify the directories in which to perform the search - we do not have to search anything, we have only one executable file.See my comment below.The AppPath should be
%ProgramFiles%\PowerShell\pwsh.exe.Since we put PowerShell in a folder with the version number we need to make a hard link
%ProgramFiles%\PowerShell -> %ProgramFiles%\PowerShell-6.0.1iSazonov commentedon Jan 29, 2018
#6027 the same for Linux
iSazonov commentedon Feb 2, 2018
We already have "App Paths" in PowerShell Core msi installer. A problem was that we used HKCU registry. This was fixed in #5915 and now we use HKLM - system wide "App Paths".
saschanaz commentedon Feb 3, 2018
I got 6.0.1 and it unfortunately still uses HKCU. Should I wait for 6.1.x?
iSazonov commentedon Feb 3, 2018
You could use current daily preview builds if you don't need official support from MSFT.
saschanaz commentedon Feb 3, 2018
I'm waiting for this to be in an official release to implement desktop/desktop#3791.