Repository navigation
Update installer to add "App Path" location for pwsh.exe #6046
Description
Activity
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 globalpwsh.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.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.
The documentation says that:
You can launch PowerShell via the Start Menu or
$env:ProgramFiles\PowerShell\pwsh.exeBut this is impossible with the installation path having version numbers. I just installed version 6.0.1 and broke my VSCode configuration.
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.1Reacted by Sobral#6027 the same for Linux
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".
Reacted by Christoph Bergmeister, Troy Campbell, Travis Plunk and Lewis RobertsI got 6.0.1 and it unfortunately still uses HKCU. Should I wait for 6.1.x?
You could use current daily preview builds if you don't need official support from MSFT.
I'm waiting for this to be in an official release to implement desktop/desktop#3791.
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
Choosing 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.