Resizing Wait-Event crashes PowerShell on macOS

[yumaikas]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

0. Be on macOS Big Sur, Version 11.6

1. Launch a PowerShell session in Terminal.

2. Run Wait-Event, then stop it via Ctrl-C

3. Run. Wait-Event again, but resize the terminal.

Expected behavior

PowerShell doesn't exit

Actual behavior

Powershell exits on terminal resize. 

If the terminal is hosted inside Neovim, it shows shows "Process exited 130", 

If the terminal is only hosted inside of the macOS Terminal.app shows "[Process completed]"

Error details

(Nothing)

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.4
PSEdition                      Core
GitCommitId                    7.1.4
OS                             Darwin 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

No response

[yumaikas]

Of note, this issue gives me a lot of grief when I run long-running foreground commands in PowerShell in Neovim, like a custom file polling script I have.

The above reproduces outside of that context.

[yumaikas]

Why does this have Issue-Question instead of Issue-Bug?

[iSazonov]

Why does this have Issue-Question instead of Issue-Bug?

Work Group will do a conclusion.

Please update your repro steps (it is not clear about Neovim).

[yumaikas]

The repro steps are updated. Is there anything further I should do to help the WG be able to attack this? I can attempt to run PowerShell Core inside a debugger, and reproduce it there, though that will take some time.

[yumaikas]

So, I found out something curious about my setup that suggests this isn't a PowerShell specific bug:

I'd set up a pwsh.nologo script to act as my interactive shell with the following

#! /bin/zsh
/usr/local/bin pwsh -Login -nologo

I noticed that running this outside of a logo environment, didn't seem to run into the same error.

Switching it to:

#! /usr/local/bin/pwsh
/usr/local/bin/pwsh -Login -nologo

Seems to get rid of this bug. Unless you want something else from me, I'll close this issue in 48 hours.

[iSazonov]

I don't think we support zsh. /cc @rjmholt

[rjmholt]

Things should work running underneath another shell. I do that a lot on Linux myself.

However, for this issue it'd be nice to rule out this being caused by zsh interfering in some way.

I will say, I'm not sure why you'd want a login script to be a PowerShell script (with the pwsh shebang) that then calls PowerShell with arguments -- that means you're starting two PowerShell processes, one within another.

I'm fairly sure you can specify arguments in a shebang, but also I think you can give them in your login shell configuration (maybe in /etc/shells?).

[yumaikas]

So, the reason I do this is because I want to able to set -Login and -nologo, and I'm totally unaware of any non-CLI flag options for doing so. I tried setting flags via /etc/shells, and that didn't work for me. So, I've created a script that just calls PowerShell, like I showed above.

Do you want me to try a different shell for my shebang line? Do environment variables exist that I could use to drive -Login/-nologo?

I've documented what I'm doing here: https://junglecoder.com/blog/pwsh-osx-nologo

PowerShell -nologo for interactive OSX shells. | Jungle Coder

[yumaikas]

I did do a decent amount of digging around trying to piece together how I got here, but this depth of customizing login shells is new territory for me, so there is a chance that I've missed something.

That being said, /bin/dash and /bin/sh both seem to not crash due to resizes, as well as /bin/pwsh, so it does look more related to zsh than pwsh.

[rjmholt]

You could try /bin/sh with the login flag -- other than zsh I don't think there's much else for default shells on macOS (I'm pretty sure bash will be taken out soon). The only thing I'd avoid is using pwsh in the shebang to start pwsh, since two pwsh startups is a lot of overhead and will be slow.

Depending on what terminal you use, you should also be able to configure the default shell invocation (certainly iTerm2 allows that).

[yumaikas]

So, it turns out that I can use exec like so:

#! /bin/zsh
exec /usr/local/bin pwsh -Login -nologo

And that works around it. I got that tip from Bart Schaefer on the zsh-workers mailing list.

Funnily enough, I think I notice more startup time using zsh than I do with nested pwsh calls.

I use kitty and/or Terminal.app atm.

[yumaikas]

From what I could tell with dtruss, the nested pwsh session seems to send a QUIT signal (or something of the like) that the zsh session isn't monitoring for.

I have ways to work around it, so it's not a critical issue at this point, more of a quirk.

For me, /etc/shells shows quite a few options:

/bin/bash
/bin/csh
/bin/dash
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/usr/local/bin/pwsh
/usr/local/bin/pwsh.nologo

[theJasonHelmick]

@yumaikas - Thanks for the issue - I haven't been able to reproduce this error using PowerShell 7.2.2 on MacOS using terminal or iTerm2. Can you confirm?

[yumaikas]

I wasn't able to reproduce it locally running pwsh from Zsh, so I think this is now working better.

[theJasonHelmick]

@yumaikas - thank you for the response -- It is possible that an upgrade to .NET may have fixed this. We tried to repo on PowerShell 7.2.x and 7.3 -- the error did not reproduce.

[ghost]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.