-
Notifications
You must be signed in to change notification settings - Fork 7.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Powershell 7 crashes when exiting from elixir's iex #11215
Comments
What is locale in your session? |
|
|
@SchrodingerZhu Thanks! Please remove PSReadline (Remove-Module PSReadline) and try again. Also what is a terminal you use? |
|
still the terminal is konsole |
|
same error with terminal |
I guess it is .Net Core issue with |
|
Looks like an issue with console ownership where PowerShell expects to own the console but does not. Looks like the place we do this in PowerShell is here. The underlying implementation of that property in *nix is here. It feels to me like PowerShell is trying to be too clever in this particular instance. My simplified mental model for how our interactive shell should host another interactive program/shell is that we synchronously cede the console to the subprocess, and then when that subprocess finishes we take it back. I'm imagining that's the intended implementation, so this might be an issue where the ConHost is not waiting for that properly. It is notable that we don't have this issue generally; just with /cc @daxian-dbw and @SteveL-MSFT since they are better versed in our console interaction logic |
|
It looks like the problem is that pwsh is sent a SIGTTIN signal (meaning pwsh doesn't have the console, so stop trying to read it), but it's not being handled. I couldn't find how to handle this in .NET Core. Opened dotnet/runtime#452 |
|
Looks like the recommend solution is to use a Mono library to handle this |
|
Why not if it is small library. |
While I'd usually propose caution on bringing a new dependency in (both for size and dependency matching reasons), this one seems especially useful to have as a shell, so agree with the proposal. |
|
I read a bit more about
And I found this PR: Investigate which signals really need to be blocked on Unix, and this comment indicates According to the description here, And here is the result It looks to me |
|
Related #8975 |
|
.NET team is not going to directly support this. @JamesWTruher has a prototype to catch signals and convert to .NET event we can use. |
|
Since current dotnet preview now contains code for handling signals, i created a private which handles |
|
The issue persists for me. However, I managed to workaround it by wraping |
|
I ran into this issue by running a build script somebody had written that started with shebang A minimal repro on my mac is running Since I'm not expecting this to be fixed anytime soon, is there some ugly workaround I can put into my powershell profile to prevent my shell process from dying? I tried "I'll start a second |
|
Unfortunately we likely need .NET to make a change here to handle signals. As for a workaround, I can't think of one if you need to explicitly have the nested shell interactive. If you can not request it to be interactive, that would not expose the issue. |
|
i believe that this is actually a dotnet issue, and I've opened: dotnet/runtime#59059 to track |
|
Shouldn't this be closed in that case? |
|
Having your shell process just crash feels pretty bad. The issue seems to still be blocked on dotnet/runtime#59059 (which was prioritized to top of backlog last release, but maybe needs another bump.) |

Step:
enter iex by
zsh -c 'iex', doube enter Ctrl-C to quit iex.Behavior:
Os info:
The text was updated successfully, but these errors were encountered: