KeyUp is requested, but why are you returning a KeyDown, especially that this KeyDown has already been returned previously?

re: emulating ConsoleHost behavior

The returned value from this local function is returned immediately at all call sites of this local function, which means the cached KeyDown returned below in if (includeUp && this.lastKeyDown != null) has already been returned previously.

@daxian-dbw

The returned value from this local function is returned immediately at all call sites of this local function, which means the cached KeyDown returned below in if (includeUp && this.lastKeyDown != null) has already been returned previously.

Yeah, that's an attempt match the behavior of ConsoleHost without dipping into native API's.

Here's an example to demonstrate what I'm trying emulate.

while ($true) {
    $Host.UI.RawUI.ReadKey('NoEcho, IncludeKeyDown')
    $Host.UI.RawUI.ReadKey('NoEcho, IncludeKeyUp')
}

With that running outside of PSES, every one key press will return two KeyInfo objects. One for down, and one for up. Example output:

VirtualKeyCode Character ControlKeyState KeyDown
-------------- --------- --------------- -------
            70         f       NumLockOn    True
            70         f       NumLockOn   False

Now obviously ConsoleHost does this a lot better using native API's directly, but this route saves a lot of complexity. The only difference in behavior is when holding down a key with both IncludeKeyUp and IncludeKeyDown set. In that scenario ConsoleHost will continuously return key down KeyInfo objects until they key is released where we will continuously return both key down and key up objects. That difference is negated a little bit though. Even ConsoleHost act the same under winpty as it doesn't translate input one to one.

Yeah on non-consolehost I think it typically only supports KeyDown events and not KeyUp at all.

If I tried that while loop on macOS, I only get KeyDown events.

Just to clarify because the terms are confusing, when I sayConsoleHost I'm referring to Microsoft.PowerShell.ConsoleHost (the PSHost started by powershell.exe/pwsh) not conhost.exe

ah sorry. Yeah I meant non-conhost sorry.

Gotcha! Thanks for the clarification!

Caller doesn't want CtrlC so throw a PipelineStoppedException to emulate a real stop.

@SeeminglyScience I'm a little confused about the comment on this throw statement. Can you please explain a bit?

Sure, so at that point we've received the input Ctrl + C. If the caller did not include AllowCtrlC in the options, then we should treat it like a break event instead and terminate the pipeline.

Emulate is probably not really the right word there, I chose it because we aren't going through PowerShell.Stop or Pipeline.Stop like a normal break event would.

Another route would be to not set Console.TreatControlCAsInput, and allow our break handler to call PowerShell.Stop like normal. This actually would be more similar to what ConsoleHost does as it will actually return default(KeyInfo), but triggers a pipeline stop.

The issue I have with this is that if RawUI.ReadKey is in an assignment statement, the pipeline stop won't actually happen until the next sequence point. PowerShell doesn't check if the current command is stopping between the RHS being evaluated and it's result being set to the LHS. So the LHS will actually be set to default(KeyInfo) instead of remaining unchanged. That doesn't happen if we throw instead.

Another route would be to not set Console.TreatControlCAsInput

Thanks! My confusion was mainly around this case. It makes sense now.

So the LHS will actually be set to default(KeyInfo) instead of remaining unchanged.

Why does this matter if the pipeline stop will kick in at the next sequence point? Even if it's set to default(KeyInfo), the script execution gets killed and that assignment shouldn't have any real effect anymore, right?

the script execution gets killed and that assignment shouldn't have any real effect anymore, right?

There's a few scenarios where it can linger:

1. LHS is a global scoped variable (or script scoped variable in a module)
2. LHS is a property or index expression
3. Current command is a prompt evaluation (or is otherwise running within the top level scope of it's SessionState)
4. If the assignment is in a try with a finally block (though it will only linger within the finally)

Can you please provide a repro of the problems? For example, LHS is a global scoped variable and it gets assigned with default(KeyInfo)

I tried with this in pwsh console

function Test{
    $global:abc = $Host.UI.RawUI.ReadKey('NoEcho, IncludeKeyDown')
}

Test
<ctrl+c>

It seems ReadKey will get either the LeftCtrlPressed or c, but not default(KeyInfo).

Here's the easiest way:

$key = $null
# Drain "Enter" key up from accepting prompt.  Maybe comment
# this line for non-Windows.
$null = $Host.UI.RawUI.ReadKey('NoEcho, IncludeKeyUp')
$key = $Host.UI.RawUI.ReadKey('NoEcho, IncludeKeyUp')

Then press Ctrl + C and $key will hold:

VirtualKeyCode Character ControlKeyState KeyDown
-------------- --------- --------------- -------
             0                         0   False

OK, I can repro it now after removing PSReadline.
Interesting that if I change IncludeKeyUp to IncludeKeyDown, it doesn't repro anymore

$null = $Host.UI.RawUI.ReadKey('NoEcho, IncludeKeyDown')
$key = $Host.UI.RawUI.ReadKey('NoEcho, IncludeKeyDown')

VirtualKeyCode Character            ControlKeyState KeyDown
-------------- ---------            --------------- -------
            17           LeftCtrlPressed, NumLockOn    True

BTW, my comment is not blocking on this PR. I'm just curious :)

OK, I can repro it now after removing PSReadline.

Huh that's surprising... mine was with PSRL as well. Though I'm on 2.0 beta 3 (or more likely one of the appveyor builds...)

Interesting that if I change IncludeKeyUp to IncludeKeyDown, it doesn't repro anymore

Wellll sorta. IncludeKeyDown makes it a lot harder to reproduce because it can trigger on a single press of Ctrl. So by the time you type C, you're actually already back to a prompt. But if you do something like this, it'll still show up

$key = $null
while ($true) {
    $key = $Host.UI.RawUI.ReadKey('NoEcho, IncludeKeyDown')
}

That will continously ReadKey until it registers Ctrl + C and a pipeline stop is triggered.

BTW, my comment is not blocking on this PR. I'm just curious :)

No worries, I could talk about it forever 🙂

Huh that's surprising... mine was with PSRL as well. Though I'm on 2.0 beta 3 (or more likely one of the appveyor builds...)

Ha, I'm using 6.2.0-rc.1.

IncludeKeyDown makes it a lot harder to reproduce because it can trigger on a single press of Ctrl. So by the time you type C, you're actually already back to a prompt.

That makes perfect sense!