Make the output of script block handler formatted and rendered to the console?

[gogsbread]

When using programs(less, fzf etc.), that emit to alternate buffers, inside ScriptBlock, there is no display of the program buffer.
For Eg:

Set-PSReadLineKeyHandler -Chord Ctrl+o -ScriptBlock { less foo.txt }

Set-PSReadLineKeyHandler -Chord Ctrl+o -ScriptBlock { find . | fzf }

Show no output

Couple of questions
a) Why is that?
b) What should I do if I need to display them? (Start separate process and redirect stdout from that process?)

[gogsbread]

Found my own answers. Documenting for reference
a) PsReadLine seems to handle pipe outputs differently using [Microsoft.PowerShell.PSConsoleReadLine] primitives. So a normal command like Set-PSReadLineKeyHandler -Chord Ctrl+o -ScriptBlock { Write-Output "Foo" } won't work.
b) Starting a new process and waiting for that process to finish shows the alternate buffer from that process. From the example above
Set-PSReadLineKeyHandler -Chord Ctrl+o -ScriptBlock { Start-Process -FilePath /usr/bin/less -ArgumentList ./foo.txt -Wait } will work

[lzybkr]

That's a reasonable workaround, but it shouldn't be necessary. Unrelated, but note that less does not use the alternate screen buffer.

The issue is how PowerShell implements ScriptBlock.Invoke which redirects stdout to capture the output. less honors this redirection and does not run interactively.

I think this is fixable in PSReadLine. This line would need to be changed, but after some quick experiments, I'm not sure how exactly. Maybe @daxian-dbw has an idea.

[daxian-dbw]

The only way I can think of is changing scriptBlock.Invoke(k, arg); to the following:

PowerShell.Create(RunspaceMode.CurrentRunspace)
    .AddScript(scriptBlock.ToString())
        .AddArgument(k)
        .AddArgument(arg)
    .AddCommand("Out-Default")
    .Invoke();

By explicitly set the downstream cmdlet to be Out-Default, we force the stdout to not be redirected when executing scriptBlock.ToString().

However, it will be a breaking change if we go with this because the scriptBlock may be a closure created by GetNewClosure(), and scriptBlock.ToString() will lose the information about the closure.

[lzybkr]

Can you use Invoke-Command instead?

[daxian-dbw]

Yup, that would work for the closure:

PowerShell.Create(RunspaceMode.CurrentRunspace)
    .AddCommand("Invoke-Command")
        .AddParameter("ScriptBlock", scriptBlock)
        .AddParameter("ArgumentList", new[] { k, arg })
    .AddCommand("Out-Default")
    .Invoke();

It will still be a behavior change though, as all the output of the script block will be written out to the console. So for any existing script block handlers that accidentally leak to the output pipe, the user will see those output written out. If we change to this, then the guideline should be don't write anything to the output pipe in the handler. Otherwise, it will go through the formatting code and slow down the handler.

Any other side effects you can think of, @lzybkr?

[SeeminglyScience]

It will still be a behavior change though, as all the output of the script block will be written out to the console. So for any existing script block handlers that accidentally leak to the output pipe, the user will see those output written out.

Or purposefully. I've been treating them like void methods, so typing anything is probably going to result in a large wall of StringBuilder spam for me. Not sure how typical that is though.

[daxian-dbw]

Alright, reopen this issue as it looks like something we are interested in improving.

[lzybkr]

The behavior change is probably OK. Arguments in favor:

• It's a major version change.
• It only affects the interactive experience.
• It only affects custom key bindings, and likely few at that.
• The workaround isn't that obvious.

I was worried it might affect modules like PSFzf but I don't think it will as that module uses the .Net api to launch fzf.

[daxian-dbw]

Note that PSReadLine doesn't know there is text rendered on the console, so when typing anything after the handler execution, the new characters will be rendered at the original cursor position and overwrite the output from the handler. This will be annoying.
It's already the case today when commands like Write-Host is used in the handler, but overall it's not too bad given that it behaves like a void method today. Making this change will have it look like we encourage rendering the handler output to the console.

[msftrncs]

Wouldn't the correct behavior for the OP's purpose be to:

1. Save the current command.
2. Cancel the command to clear the prompt. (RevertLine())
3. Enter the desired command on the commandline via SelfInsert() or similar.
4. Execute the command (AcceptLine()).
5. Restore the original command.

This way keybinding handlers can remain void. The desired command could even be a [psconsolereadline]::method() if needed, but should, if complexity requires, be implemented as a PowerShell function. This would resolve the issue of output in the middle of editing.

I'll admit, I do not know if all the required services to implement this are available.

[lzybkr]

Running via AcceptLine might be an option, but there are likely unintended consequences like unwanted commands in your history.

Also - the command you launch would have to be the last (only?) command in your scriptblock - you couldn't do anything afterwards which could be a deal breaker for some useful extensions.