Rename powershell.exe to pwsh.exe #5101

SteveL-MSFT · 2017-10-12T23:54:52Z

renamed powershell.exe to pwsh.exe
updated powershell core code dependencies, console host references, and tests
updated vscode json files
updated docker files
updated logic in moduleintrinsics.cs to account for SxS where you are starting pwsh from powershell.exe

Fix #4214

daxian-dbw · 2017-10-13T18:37:13Z

demos/SSHRemoting/README.md

@@ -173,7 +173,7 @@ Microsoft Windows [Version 10.0.10586]
 #
 # Windows to Windows
 #
-C:\Users\PSUser\Documents>"C:\Program Files\PowerShell\6.0.0.17\powershell.exe"
+C:\Users\PSUser\Documents>pwsh.exe


The full path is removed here. Is this because we are putting it to %PATH%?

We should update the msi installer to add it to %PATH%, I wanted to remove it since it references a specific version path. I'll do the msi update separate from this PR.

daxian-dbw · 2017-10-13T20:47:17Z

test/powershell/Host/TabCompletion/TabCompletion.Tests.ps1

@@ -418,7 +418,7 @@ Describe "TabCompletion" -Tags CI {
                @{ inputStr = 'gmo -list PackageM'; expected = 'PackageManagement'; setup = $null }
                @{ inputStr = 'gcm -Module PackageManagement Find-Pac'; expected = 'Find-Package'; setup = $null }
                @{ inputStr = 'ipmo PackageM'; expected = 'PackageManagement'; setup = $null }
-                @{ inputStr = 'Get-Process powersh'; expected = 'powershell'; setup = $null }
+                @{ inputStr = 'Get-Process pws'; expected = 'pwsh'; setup = $null }


A typo -- pws

This is for the tab completion test so pws completes to pwsh since there isn't necessarily a powershell process anymore and pw might resolve to something else

Ah, yes, my mistake.

renamed powershell.exe to pwsh.exe

SteveL-MSFT · 2017-10-13T21:50:46Z

rebased to fix merge conflict

fixed check in appveyor.psm1

PaulHigin · 2017-10-13T22:06:08Z

src/Microsoft.PowerShell.ScheduledJob/ScheduledJobDefinition.cs

@@ -42,7 +42,7 @@ public sealed class ScheduledJobDefinition : ISerializable, IDisposable
        private bool _isDisposed;

        // Task Action strings.
-        private const string TaskExecutionPath = @"powershell.exe";
+        private const string TaskExecutionPath = @"pwsh.exe";


This code assumes a discoverable pwsh.exe native command. Does this fix include adding pwsh.exe to the system path environment variable? If so what version? I wonder if we should allow the user to select a powershell.exe or pwsh.exe path to use for scheduled jobs (maybe in a separate issue/pr).

Maybe we should use Utils.DefaultPowerShellAppBase here as we do with PowerShellProcessInstance.cs to ensure the scheduled job is using the correct path.
The problem with scheduled jobs is that they can run indefinitely on a machine and if pwsh.exe is uninstalled or installed to a new location then they will break. Of course we have a similar problem with credentials expiring.

I have a separate PR coming for the msi installer to append to %PATH% which would also solve the Win+R->pwsh usage

If PSCore6 is uninstalled, the full path won't help either.

Actually, I'll do the %PATH% msi change as part of this PR as it's more useful that pwsh.exe differs form powershell.exe and I can put it at the end of the path rather than taking over the front

PaulHigin · 2017-10-13T22:17:36Z

src/System.Management.Automation/engine/remoting/common/RunspaceConnectionInfo.cs

@@ -3166,7 +3166,7 @@ private void CreateContainerProcessInternal()
                    // Windows Server container (i.e., RuntimeId is empty) uses named pipe transport for now.
                    //
                    cmd = string.Format(System.Globalization.CultureInfo.InvariantCulture,
-                        @"{{""CommandLine"": ""powershell.exe {0} -NoLogo {1}"",""RestrictedToken"": {2}}}",
+                        @"{{""CommandLine"": ""pwsh.exe {0} -NoLogo {1}"",""RestrictedToken"": {2}}}",


Same issue here in that we rely on a "built-in" pwsh.exe command that is discoverable. But we have the same issue with ssh.exe used for SSH based remoting.

Actually as I think about it, we don't want to change this here. This is a command run on a target VM and relies on the built-in Windows PowerShell. pwsh.exe will not be available on a new VM.

So this command is run within the VM expecting Windows PowerShell?

Ok, will change back.

updated msi to include pwsh in path and app paths reverted change for hyper-v powershell direct reapplied test changes reverted by rebase

PaulHigin

LGTM

SteveL-MSFT · 2017-10-16T18:02:03Z

@daxian-dbw can you review again since last commit?

daxian-dbw · 2017-10-16T18:22:29Z

src/System.Management.Automation/engine/Modules/ModuleIntrinsics.cs

@@ -791,8 +793,9 @@ private static string RemoveSxSPsHomeModulePath(string currentProcessModulePath,
                {
                    string parentDir = Path.GetDirectoryName(trimedPath);
                    string psExePath = Path.Combine(parentDir, powershellExeName);
+                    string oldExePath = Path.Combine(parentDir, oldPowershellExeName);
                    string psDepsPath = Path.Combine(parentDir, "powershell.deps.json");


Once you change it to pwsh in csproj, I guess the .deps.json file will be changed to pwsh.deps.json.
But maybe you want to keep the check for powershell.deps.json for now just like the check for old "powershell.exe".

Yeah, it did get changed to pwsh.deps.json, will add oldDepsPath

@daxian-dbw Do we really even need the deps.json check?

I remember we didn't have the .deps.json check initially and it caused a build break and the fix was to add this deps.json check. Here is the related issue #1744 and #1792

Not sure if that requirement is applicable now.

I'll keep it for now

daxian-dbw · 2017-10-16T18:22:46Z

assets/Product.wxs

+            </Component>
+            <!-- add ourselvs to %PATH% so pwsh.exe can be started from Windows PowerShell or cmd.exe -->
+            <Component Id="SetPath" Guid="{9dbb7763-7baf-48e7-b025-3bdedcb0632f}">
+              <Environment Id="PATH" Action="set" Name="PATH" Part="last" Permanent="yes" System="yes" Value="[$(var.ProductVersionWithName)]"/>


Do we remove the path when uninstalling the package?

daxian-dbw · 2017-10-16T18:23:18Z

src/System.Management.Automation/engine/Modules/ModuleIntrinsics.cs

 #else
            const string powershellExeName = "pwsh.exe";
+            const string oldPowershellExeName = "powershell.exe";


Shall we remove the old exe name when we reach RC/RTM?

I think this is still needed if we start pwsh from Windows PowerShell

I think the "start pwsh from windows powershell" case is handled in NeedToClearProcessModulePath, and RemoveSxSPsHomeModulePath only handles powershell core.

Because of the .deps.json file check, this doesn't apply to Windows PowerShell anyways. We can remove at RC/GA

Then I will open an issue on this -- #5135

daxian-dbw · 2017-10-16T18:24:15Z

src/System.Management.Automation/engine/remoting/common/RunspaceConnectionInfo.cs

@@ -3166,7 +3166,7 @@ private void CreateContainerProcessInternal()
                    // Windows Server container (i.e., RuntimeId is empty) uses named pipe transport for now.
                    //
                    cmd = string.Format(System.Globalization.CultureInfo.InvariantCulture,
-                        @"{{""CommandLine"": ""pwsh.exe {0} -NoLogo {1}"",""RestrictedToken"": {2}}}",
+                        @"{{""CommandLine"": ""powershell.exe {0} -NoLogo {1}"",""RestrictedToken"": {2}}}",


A comment explaining why powershell.exe is used here will be helpful when looking at this code in future.

daxian-dbw · 2017-10-16T21:16:40Z

@SteveL-MSFT One more issue: when creating Unix packages, symbolic link is created to point to powershell in $pshome (see the following places). You need to update the symbolic link file name and the target file name.

Besides, are you planning to change the package name? (I assume not).

https://github.com/PowerShell/PowerShell/blob/master/tools/packaging/packaging.psm1#L459
https://github.com/PowerShell/PowerShell/blob/master/tools/packaging/packaging.psm1#L471
https://github.com/PowerShell/PowerShell/blob/master/tools/packaging/packaging.psm1#L587

SteveL-MSFT · 2017-10-16T21:23:29Z

@daxian-dbw will update the symlink, the package name is not changing

address PR feedback

TravisEz13 · 2017-10-16T22:45:31Z

test/docker/networktest/Dockerfile

@@ -1,7 +1,7 @@
 # escape=`
 FROM microsoft/windowsservercore

-SHELL ["powershell.exe","-command"]
+SHELL ["pwsh.exe","-command"]


Please don't break docker... there are tests in docker/tests. All tests can be can be run from windows, just run them once with the docker daemon set to windows mode and once set to Linux mode.

This is before PSCore has been installed. So this won't work.

Sorry, just notice this is a test file, not a production docker file.

missed test generating fake .deps.json file no longer need code in packaging.psm1 to ensure binaries are named correctly (since dotnet does it correctly now) updated symlinks in packaging, didn't update $name value since it appears to be used for the package name which isn't changing

daxian-dbw

I did some more updates to the packaging.psm1 regarding the name change.

I think we also need to update the docker files, including those in docker/release and tools\releaseBuild\Images. But I'm OK if you want to do that in a separate PR.

daxian-dbw · 2017-10-17T18:13:18Z

src/System.Management.Automation/engine/Modules/ModuleIntrinsics.cs

+                    string oldExePath = Path.Combine(parentDir, oldPowershellExeName);
+                    string psDepsPath = Path.Combine(parentDir, powershellDepsName);
+                    string oldDepsPath = Path.Combine(parentDir, oldPowershellDepsName);
+                    if ((File.Exists(psExePath) && File.Exists(psDepsPath)) || (File.Exists(oldDepsPath) && File.Exists(oldDepsPath)))


(File.Exists(oldDepsPath) && File.Exists(oldDepsPath))

One of them should be oldExePath

SteveL-MSFT · 2017-10-17T22:57:35Z

Let's do the docker updates as separate PR

fix check for SxS

tmknight · 2017-10-29T13:14:08Z

Shouldn't this be an alias vs a complete rename? Please point me to the discussion where the decision to rename took place. Thanks

markekraus · 2017-10-29T15:27:24Z

@tmknight here is where the PowerShell comitee's decision was announced: #4214 (comment)

SteveL-MSFT assigned daxian-dbw Oct 12, 2017

SteveL-MSFT requested review from daxian-dbw, JamesWTruher and adityapatwardhan October 12, 2017 23:54

SteveL-MSFT requested review from anmenaga, BrucePay, dantraMSFT, HemantMahawar, joeyaiello, lzybkr, mirichmo, PaulHigin, TravisEz13 and vors as code owners October 12, 2017 23:54

SteveL-MSFT force-pushed the pwsh branch 5 times, most recently from b516aed to 7dd72f9 Compare October 13, 2017 17:36

SteveL-MSFT added the Breaking-Change breaking change that may affect users label Oct 13, 2017

daxian-dbw requested changes Oct 13, 2017

View reviewed changes

daxian-dbw approved these changes Oct 13, 2017

View reviewed changes

[feature]

d948bf6

renamed powershell.exe to pwsh.exe

SteveL-MSFT force-pushed the pwsh branch from 7dd72f9 to d948bf6 Compare October 13, 2017 21:49

[feature]

d992c7b

fixed check in appveyor.psm1

daxian-dbw approved these changes Oct 13, 2017

View reviewed changes

PaulHigin suggested changes Oct 13, 2017

View reviewed changes

SteveL-MSFT force-pushed the pwsh branch 2 times, most recently from 04257cd to d426d98 Compare October 14, 2017 01:36

[feature]

b4daecd

updated msi to include pwsh in path and app paths reverted change for hyper-v powershell direct reapplied test changes reverted by rebase

SteveL-MSFT force-pushed the pwsh branch 2 times, most recently from b4daecd to da7e7fe Compare October 14, 2017 02:23

PaulHigin approved these changes Oct 16, 2017

View reviewed changes

daxian-dbw requested changes Oct 16, 2017

View reviewed changes

[feature]

4227515

address PR feedback

SteveL-MSFT force-pushed the pwsh branch 2 times, most recently from fc91109 to b4a10fa Compare October 16, 2017 22:30

TravisEz13 reviewed Oct 16, 2017

View reviewed changes

SteveL-MSFT force-pushed the pwsh branch from b4a10fa to 26f92f4 Compare October 16, 2017 23:05

Some more updates to packaging.psm1

a5e7240

daxian-dbw requested changes Oct 17, 2017

View reviewed changes

[feature]

b41e048

fix check for SxS

daxian-dbw approved these changes Oct 17, 2017

View reviewed changes

daxian-dbw merged commit 2cc0911 into PowerShell:master Oct 18, 2017

SteveL-MSFT deleted the pwsh branch October 18, 2017 01:48

bergmeister mentioned this pull request Oct 18, 2017

Create pwsh as a shorter name for calling powershell.exe #4214

Closed

thezim mentioned this pull request Oct 19, 2017

Update PowerShell macOS launcher to pwsh. #5174

Merged

bergmeister mentioned this pull request Jan 4, 2018

Directory for $PSHome when updating on Windows with MSI #5226

Closed

iSazonov mentioned this pull request Jan 27, 2018

Task Scheduler Compatibility Problem #5919

Closed

Rename powershell.exe to pwsh.exe #5101

Rename powershell.exe to pwsh.exe #5101

Uh oh!

Conversation

SteveL-MSFT commented Oct 12, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteveL-MSFT commented Oct 13, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PaulHigin left a comment

Choose a reason for hiding this comment

Uh oh!

SteveL-MSFT commented Oct 16, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteveL-MSFT Oct 16, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteveL-MSFT Oct 16, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daxian-dbw Oct 16, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

daxian-dbw commented Oct 16, 2017

Uh oh!

SteveL-MSFT commented Oct 16, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SteveL-MSFT commented Oct 12, 2017 •

edited

Loading

SteveL-MSFT Oct 16, 2017 •

edited

Loading

SteveL-MSFT Oct 16, 2017 •

edited

Loading

daxian-dbw Oct 16, 2017 •

edited

Loading

daxian-dbw left a comment •

edited

Loading