PowerShell preview executables no longer at /usr/[local/]bin/pwsh on *nix

[rjmholt]

PowerShell 6.1.0-preview.3 will install its executable as pwsh-preview as of the upcoming release.

We will need to work out how to handle this.

@s2p16 reported this and a workaround here: PowerShell/PowerShell#6132 (comment).

Essentially, for now, the best solution is to specify a new powerShellExePath:

{
  "powershell.powerShellExePath": "/usr/bin/pwsh-preview"
}

Another alternative would be to use @rkeithhill's EXE path feature:
#1270

But we should also fix this so that it works out of the box. Since preview and ordinary releases are now allowed side-by-side, we should figure out which we prefer if both are present.

[s2p16]

I will suggest powershell extensions in visual studio code could allow you to choose which one to use in a project basis, saving the setting into .vscode or similar (something similar that is already doing with the typescript engine). I am saying that ps extensions on code should support both executables, enable to choose one per project in case both are detected.

[rjmholt]

@s2p16 we already support a feature like that with #1270.

The main issue here is that the default PowerShell executable path is going to need changing with newer PowerShell releases.

For that, I think a change will need to be made here:

vscode-powershell/src/platform.ts

Lines 50 to 83 in 9bf58a7

	export function getDefaultPowerShellPath(
	platformDetails: IPlatformDetails,
	use32Bit: boolean = false): string | null {
	let powerShellExePath;
	// Find the path to powershell.exe based on the current platform
	// and the user's desire to run the x86 version of PowerShell
	if (platformDetails.operatingSystem === OperatingSystem.Windows) {
	if (use32Bit) {
	powerShellExePath =
	platformDetails.isOS64Bit && platformDetails.isProcess64Bit
	? SysWow64PowerShellPath
	: System32PowerShellPath;
	} else {
	powerShellExePath =
	!platformDetails.isOS64Bit || platformDetails.isProcess64Bit
	? System32PowerShellPath
	: SysnativePowerShellPath;
	}
	} else if (platformDetails.operatingSystem === OperatingSystem.MacOS) {
	powerShellExePath = "/usr/local/bin/powershell";
	if (fs.existsSync("/usr/local/bin/pwsh")) {
	powerShellExePath = "/usr/local/bin/pwsh";
	}
	} else if (platformDetails.operatingSystem === OperatingSystem.Linux) {
	powerShellExePath = "/usr/bin/powershell";
	if (fs.existsSync("/usr/bin/pwsh")) {
	powerShellExePath = "/usr/bin/pwsh";
	}
	}
	return powerShellExePath;
	}

[s2p16]

Thanks for the information!
I see...
for an easy workaround the function getDefaultPowerShellPath may return an enumerable of {
versionName: [version_name],
exePath: [exePath],
} and the function getAvailablePowerShellExes must add all them instead of just resolving the path as it's doing now.

[rkeithhill]

I would think that the "default" PowerShell on Windows should still be Windows PoweShell at this time, right? As for macOS/Linux, should the default be pwsh if both pwsh and pwsh-preview are installed? Defaulting to a "stable" version seems like the right approach, as long as we make it easy to switch to the preview. OTOH, if only pwsh-preview is installed the choice is easy. :-)

The extension will remember your setting if you choose PS Core. And as @rjmholt, we already have a means to specify the PowerShell edition/version per workspace. We need to update geAvailablePowerShellExes to find these preview versions. It would be nice to get this in for the upcoming update. I can see what I can get done here while I'm waiting on my son to finish his swim practice. :-)

[s2p16]

Yes, you're right,
I was trying to enable user interaction at session start when no defaults is set, allowing to choose option 1 pwsh and 2 -preview, but this requires some signature change and a bit of more lines in other source files. It may not follow the easy thing xD
But it will prevent the user experimenting the same problem I was running on visual studio code whit vs-code-extensions while the stable version is not fixed.