Switch-Process, when used to replace the PowerShell process with an interactive (different) shell session, breaks that session

[mklement0]

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

Clearly not a common use case, but a bug nonetheless:

When you use Switch-Process (exec) to replace the current PowerShell process (running an interactive session) with a different shell's interactive session (e.g., bash), that session's command-line editing is broken.

# Run on macOS or Linux
Switch-Process /bin/bash

Expected behavior

A regular interactive Bash session.

Actual behavior

What the user types on the Bash command line doesn't print (however, submitting commands and printing output works normally).

Error details

No response

Environment data

PowerShell Core 7.3.0-rc.1 on macOS 12.6 or Linux

Visuals

No response

[237dmitry]

What the user types on the Bash command line doesn't print (however, submitting commands and printing output works normally).

The same on Linux. And you can't switch back, exit closes the terminal.

[mklement0]

Thanks for confirming that the problem also affects Linux, @237dmitry (I've updated the initial post).

exit closes the terminal

That is actually by design: Switch-Process (exec) is meant to replace the current process rather than create a child process. Therefore , bash becomes the process running directly in the terminal window, and exiting it closes the window.

[237dmitry]

is meant to replace the current process rather than create a child process.

I understood. But it is unclear why this is necessary? You can simply run another shell right in the current session, in a different buffer, so as not to lose information in the main buffer.

"`e[?1049h"; Clear-Host; bash; "`e[?1049l"

[mklement0]

As stated in the initial post, this use of exec is uncommon - you'd only do this if you wanted to discard the PowerShell session in favor of a different shell's interactive session, without needing to return to it.

That said, (a) it should still work and (b), not knowing what the underlying problem is, more common exec scenarios could be affected too (say a non-shell replacement process prompts for user input).

[237dmitry]

you'd only do this if you wanted to discard the PowerShell session in favor of a different shell's interactive session, without needing to return to it.

Ok.

[SteveL-MSFT]

Using switch-process with zsh works as expected, but bash seems to not set the echo mode (tested on MacOS). Workaround is to use stty echo within bash. Based on what I could find, we may have to use termios to re-enable echo before exec call.

[SteveL-MSFT]

So, I don't think calling termios may be sufficient as stty already has echo on within pwsh and that doesn't resolve bash issue.

[mklement0]

Not sure how relevant it is in the real world, but ksh is also affected (as is dash, but no one uses that as an interactive shell); by contrast, fish, like zsh, is not affected.

[SteveL-MSFT]

I'm guessing that fish, zsh, etc... is explicitly setting stty to echo whereas older shells do not. Don't understand what other shells are doing to make it work. Here's something that's a bit interesting:

PS> stty
speed 38400 baud;
lflags: echoe echok echoke echoctl pendin
iflags: iutf8
oflags: -oxtabs
cflags: cs8 -parenb
[61.39ms] /Users/steve
PS> pwsh -c { exec stty }
speed 38400 baud;
lflags: echoe echok echoke echoctl pendin
iflags: iutf8
oflags: -oxtabs
cflags: cs8 -parenb
[318.76ms] /Users/steve
PS> pwsh
PowerShell 7.3.0-rc.1
/Users/steve
PS> exec stty
speed 38400 baud;
lflags: -icanon -iexten -echo echoe echok echoke echoctl pendin
iflags: -icrnl -ixon iutf8
oflags: -oxtabs
cflags: cs8 -parenb

So interactive mode for PowerShell is doing something affecting the tty.

[daxian-dbw]

Instead of PowerShell, It could be what .NET does, or more specifically, what [Console]::Readkey does. The following is quoted from the blog about "Console.ReadKey" improvement:

tcsetattr allows for changing the terminal settings. It’s used by .NET to apply its own setting at startup, and restore the previous settings at rundown.