pwsh as a dotnet global tool exhibits very unusual behavior with Ctrl-C

[DHowett-MSFT]

Steps to reproduce

Install powershell as a dotnet global tool. Run a long-running thing (like Start-Sleep), and then press Ctrl+C

Expected behavior

I am returned to a powershell prompt.

C:\Users\duhowett>.\.dotnet\tools\pwsh
PowerShell 6.2.3

(dhowett-dev2) ~ % start-sleep 10
^C
(dhowett-dev2) ~ % # i am returned to a powershell prompt

Actual behavior

The dotnet tool shim hosting powershell terminates and returns control to cmd, but powershell remains connected to the console and reads input simultaneously. PowerShell and CMD share the input buffer, and neither of them can agree on what goes into it.
If you manage to exit cmd, powershell re-asserts control.

The dir in the snippet below came from cmd

C:\Users\duhowett>.\.dotnet\tools\pwsh
PowerShell 6.2.3

(dhowett-dev2) ~ % start-sleep 10
^C
C:\Users\duhowett>
(dhowett-dev2) ~ % dir
 Volume in drive C is Cesium
 Volume Serial Number is E499-450A

 Directory of C:\Users\duhowett

The blue d came from powershell, and the ir came from cmd.

Environment data

Name                           Value
----                           -----
PSVersion                      6.2.3
PSEdition                      Core
GitCommitId                    6.2.3
OS                             Microsoft Windows 10.0.19041
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[Zenexer]

This isn't limited to pwsh as a dotnet global tool. pwsh.exe exits whenever Ctrl + C is pressed in a long-running child process if pwsh.exe has been invoked from another terminal, e.g. powershell.exe or cmd.exe. This makes it impossible to kill long-running native commands without also killing the whole terminal.

For example, the following works as expected:

1. Press Win + R
2. Type pwsh.exe
3. Press Enter
4. Run a long-running native command in pwsh (an EXE, not a cmdlet)
5. Press Ctrl + C while the command is running
6. The command will exit; pwsh will not

However, the following occurs, but isn't expected behavior:

1. Press Win + R
2. Type cmd.exe
3. Press Enter
4. Run a long-running native command in pwsh (an EXE, not a cmdlet)
5. Press Ctrl + C while the command is running
6. Both the command and pwsh exit; you're brought back to cmd.exe.

The following unexpected behavior also occurs, as described in #3869:

1. Open a PowerShell Core session in Windows Terminal
2. Run a long-running native command in pwsh (an EXE, not a cmdlet)
3. Press Ctrl + C while the command is running
4. Both the command and pwsh exit; the Windows Terminal tab will close.

This means pwsh is very difficult to use for anything serious in Windows Terminal, since cancelling a command kills the whole shell.

[Zenexer]

Update: I was on 6.2.3 when I observed that behavior. I've since installed 7.0.0-rc1 and am no longer able to reproduce it. There's a possibility I had installed it as a dotnet global tool before, but I thought I downloaded it directly from GitHub. This time I installed it via the MSI on GitHub.

[bgshacklett]

FWIW, I'm seeing this behavior in Windows Terminal with PowerShell installed via https://scoop.sh. Both 6.2.3 and 7.0.0-rc1 are acting similarly for me. Here's the output from 7.0.0-rc1:

C:\Users\brian>where pwsh
C:\Users\brian\scoop\shims\pwsh.exe

C:\Users\brian>pwsh --version
PowerShell 7.0.0-rc.1

C:\Users\brian>pwsh
PowerShell 7.0.0-rc.1
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/powershell
Type 'help' to get help.

PS C:\Users\brian> start-sleep 10
^C
C:\Users\brian>
PS C:\Users\brian> gci
'gci' is not recognized as an internal or external command,
operable program or batch file.

Starting in cmd.exe, we can see that PowerShell version 7.0.0-rc.1 is the default pwsh and is located at C:\Users\brian\scoop\shims\pwsh.exe.

Running start-sleep 10, then pressing ctrl+c to stop the sleep results in a return to cmd.exe, with the PS prompt being output once for some reason. Attempting to run a PowerShell cmdlet results in a failure showing that we are, in fact, in cmd.exe.

Scoop

[DHowett-MSFT]

Unless Scoop is using the dotnet global tool wrapper shipped with PowerShell, this is likely an issue affecting all Scoop-shimmed console-subsystem binaries. It’s almost certainly worth filing a duplicate of this issue on them so they can fix it for everyone.

[DenisBalan]

Powershell Core installed as dotnet global tool.
same behaviour (only under windows terminal) on Compress-Archvie func, while asking for Path[0], press CTRL+C, no scoop installed.

Name                           Value
----                           -----
PSVersion                      6.2.4
PSEdition                      Core
GitCommitId                    6.2.4
OS                             Microsoft Windows 10.0.19555
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

cmdlet Compress-Archive at command pipeline position 1
Supply values for the following parameters:
Path[0]:
[process exited with code 3221225786]

[DHowett-MSFT]

Yes- this happens because Windows Terminal tracks the process that it has spawned, which in this case is the dotnet global tool wrapper. The wrapper is intercepting ^C and terminating when it shouldn’t.

[shanselman]

@SteveL-MSFT This is interesting and we should figure this out. I means that anyone using PowerShell like this loses the whole process when pressing Ctrl-C

@KathleenDollard for visibility. This makes PowerShell installed as a dotnet global tool not really usable.

[ssg]

This happens so frequently, like whenever I want to stop the output of a long "dir" with Ctrl-C that I had to stop using Windows Terminal.

[shanselman]

@ssg I am very sympathetic and I'll work to get it fixed, but a better solution would be to NOT use Pwsh as a .NET global Tool. Just install PowerShell Core and you won't have this issue and you can use Windows Terminal.

[inv2004]

Please increase priority of the issue, I just moved from conemu, but the bug makes terminal+core near useless for work.

[SteveL-MSFT]

As noted, current mitigation is to install via the MSI or zip instead.

[inv2004]

@SteveL-MSFT
It is clear about msi, thank you.

Could you please clarify about zip, because I supposed that it is the same that scoop does.

[SteveL-MSFT]

@inv2004 we also publish a zip pkg for Windows. You can just unzip and run the contained pwsh executable. I don't use scoop myself, so can't comment on that. The team is currently busy with the rc.3 release, so perhaps someone can look at it to understand the complexity of a fix after that. Can't commit to be addressed by 7.0 GA, but we can service it with a 7.0.1 release once a fix is understood.

[ssg]

@shanselman This workaround is great and it works, thanks! But the first hit on Google for downloading PowerShell Core still suggests dotnet global tool as the first option in the Tip box, and doesn't warn the user about implications, could it be revised at least?: https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-windows?view=powershell-7

Installing PowerShell Core on Windows - PowerShell

Information about installing PowerShell Core on Windows

[shanselman]

Personally, I agree @ssg that while PowerShell Core installed via a .NET Global Tool would be the ideal way to get PWSH on a machine, we shouldn't recommend it OR we should include a warning that it won't work with Windows Terminal for now. @sdwheeler @KathleenDollard

[brad-jones]

Unless Scoop is using the dotnet global tool wrapper shipped with PowerShell, this is likely an issue affecting all Scoop-shimmed console-subsystem binaries. It’s almost certainly worth filing a duplicate of this issue on them so they can fix it for everyone.

Pretty simple fix in the end, just wasn't immediately obvious to me so here is what I did.

Just edit Windows Terminal settings such that your using pwsh.exe directly and not using the scoop shim.

Originally I had:

{
    "guid": "{b91d6aa8-b68c-416b-89b4-f29a2abebdcd}",
    "name": "Windows PowerShell Core",
    "commandline": "pwsh.exe", // which resolves to C:\Users\brad.jones\scoop\shims\pwsh.exe
    "hidden": false,
    "fontSize": 10,
    "padding": "1",
    "icon": "C:\\Users\\brad.jones\\Pictures\\PowerShell_Core_6.0_icon.png",
    "startingDirectory": "%USERPROFILE%"
}

Updated to:

{
    "guid": "{b91d6aa8-b68c-416b-89b4-f29a2abebdcd}",
    "name": "Windows PowerShell Core",
    "commandline": "C:\\Users\\brad.jones\\scoop\\apps\\powershell-core\\current\\pwsh.exe",
    "hidden": false,
    "fontSize": 10,
    "padding": "1",
    "icon": "C:\\Users\\brad.jones\\Pictures\\PowerShell_Core_6.0_icon.png",
    "startingDirectory": "%USERPROFILE%"
}

[inv2004]

@brad-jones
Awesome. So simple and I can confirm that it works perfect.

            "commandline": "%USERPROFILE%\\scoop\\apps\\pwsh\\current\\pwsh.exe",

[burzum]

I agree with @ssg, the docs should mention that you need to use the msi package and not the dotnet tool installation. Searching for the cause of the problem finally brought me this issue here. I hope this is going to get fixed soon. Besides that: Nice job! The new terminal might replace cmdr for me. 👍

[ghost]

🎉This issue was addressed in #11959, which has now been successfully released as v7.0.0.:tada:

Handy links:

• Release Notes

[pcgeek86]

I can confirm this is still a problem with PowerShell 7.0.0 on Windows 10 build 1909 with Windows Terminal 0.11.1251.0

@SteveL-MSFT please re-open the ticket

[f0ff886f]

Are you using scoop? If you're using scoop then you need to make sure you're not using the global shim for pwsh.exe and use scoop/apps/pwsh/current/pwsh.exe or replace your shim with the C-based alternative that doesn't come with showstopping problems like the one above, see ScoopInstaller/Scoop#3634

[pcgeek86]

I installed PowerShell 7 with Scoop. Here is the default configuration in Windows Terminal. It's using source instead of commandline.

            {
                "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}",
                "hidden": false,
                "name": "PowerShell",
                "source": "Windows.Terminal.PowershellCore",
		"colorScheme": "Galaxy"
            }

[f0ff886f]

Then replace your shims and it'll start working. it's a scoop issue, not a powershell issue.

[younger-1]

Unless Scoop is using the dotnet global tool wrapper shipped with PowerShell, this is likely an issue affecting all Scoop-shimmed console-subsystem binaries. It’s almost certainly worth filing a duplicate of this issue on them so they can fix it for everyone.

Pretty simple fix in the end, just wasn't immediately obvious to me so here is what I did.

Just edit Windows Terminal settings such that your using pwsh.exe directly and not using the scoop shim.

Originally I had:

{
    "guid": "{b91d6aa8-b68c-416b-89b4-f29a2abebdcd}",
    "name": "Windows PowerShell Core",
    "commandline": "pwsh.exe", // which resolves to C:\Users\brad.jones\scoop\shims\pwsh.exe
    "hidden": false,
    "fontSize": 10,
    "padding": "1",
    "icon": "C:\\Users\\brad.jones\\Pictures\\PowerShell_Core_6.0_icon.png",
    "startingDirectory": "%USERPROFILE%"
}

Updated to:

{
    "guid": "{b91d6aa8-b68c-416b-89b4-f29a2abebdcd}",
    "name": "Windows PowerShell Core",
    "commandline": "C:\\Users\\brad.jones\\scoop\\apps\\powershell-core\\current\\pwsh.exe",
    "hidden": false,
    "fontSize": 10,
    "padding": "1",
    "icon": "C:\\Users\\brad.jones\\Pictures\\PowerShell_Core_6.0_icon.png",
    "startingDirectory": "%USERPROFILE%"
}

Awesome workaround!
For me, may this is more concise~

"commandline": "%SCOOP%/apps/pwsh/current/pwsh.exe"

[spyder007]

For what it's worth, and for those who might not know the difference:

When using chocolatey, installing the powershell.portable will give you the "dotnet global" behavior and will close when Ctrl-C is pressed on a long running task.

Install the powershell-core chocolatey package instead.