Set-Clipboard -Remote with OSC52

[dkaszews]

Summary of the new feature / enhancement

Set-Clipboard does not really work over SSH, as it always sets the clipboard of the target machine, not the host. This means that if you SSH e.g. from your PC to a server, then Set-Clipboard will set the server's clipboard, not your PCs, so you cannot paste it anywhere.

This can be resolved by using ANSI escape sequence (same mechanism as for setting colors) OSC52, which sets the clipboard of the host machine, which in our example is the PC, so you can paste it anywhere. This sequence is supported by most terminals, including Microsoft Terminal.

Example:

function Set-RemoteClipboard($text) {
    Write-Host "`e]52;;$([System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($text)))`a"
}
# Copy "original" into a clipboard from anywhere
> Set-Clipboard 'changed'
# Press Ctrl+Shift+V to see clipboard still "original"
> Set-RemoteClipboard 'changed'
# Press Ctrl+Shift+V to see clipboard now "changed"

OSC also has similar Get-Clipboard -Remote sequence, but no terminal implements it as it is rightly considered a security and privacy risk, and you ca simply "get" the host clipboard with Ctrl+Shift+V.

Opens:

1. Should we autodetect when to use the OSC52 instead of xclip or other OS target-implementation? E.g. SSH can be detected by presence of environment variables $env:SSH_CLIENT and $env:SSH_TTY. I would say no, as it could be potentially breaking behavior in case of false positives on terminals which don't support the OSC. If user wants such behavior, they can add $PSDefaultParameters['Set-Clipboard:Remote'] = $env:SSH_CLIENT -or $env:SSH_TTY to their $PROFILE.
2. Some terminal multiplexers like screen and tmux may require wrapping OSC52 into a different escape, as can be seen in the vim plugin implementation. Should we detect and handle those cases? tmux can be forced to work with default escape by setting set -s set-clipboard on. I would say keep it simple for now, then maybe add -RemoteMethod = auto | osc52 | tmux | screen in separate issue if required.

Proposed technical implementation details (optional)

See example for the escape sequence format.

[237dmitry]

OSC52 does not work on local linux in either pwsh or bash. At least in those virtual terminals that I use. And which base64-string is in correct format?

$a = "test" | base64   
$b = [convert]::ToBase64String([text.encoding]::UTF8.GetBytes("test"))
$a
$b

# dGVzdAo=
# dGVzdA== 

[jhoneill]

I was just about to say something similar to @237dmitry

This is a good idea, but there doesn't appear to be any way for the remote session to know what OSC commands are supported (see also https://github.com/PowerShell/PowerShell/issues/18098#issuecomment-1249224249 ) . It is a useful thing to add but may cause wrong expectations if it is the default

@237dmitry the two formats

dGVzdAo= <--- Contains "test" with a trailing Line feed
dGVzdA== <--- Contains "test" only.

I'm guessing the latter is preferred but the former is mostly harmless.

[dkaszews]

@237dmitry Vim plugin lists supported terminals, unfortunately GNOME and Konsole which are two popular Linux ones don't support it.

@jhoneill Agreed that without universal support using it as default is not a good idea. However the support is broad enough (I may be biased because Windows Terminal and Chromebook hterm are the only two I use) it would be useful to have it. Just put in help that it may not work on all terminals, so test before relying on it.

[SteveL-MSFT]

@PowerShell/wg-powershell-cmdlets We see utility, although perhaps not common, with this feature. We propose adding a -AsOSC52 switch to enable this behavior. Since not all terminals support this and those that do may require additional setting change to enable it, the switch name makes it easier to find relevant documentation.

[dkaszews]

I'm working on implementation, got stuck on a stupid issue - how do I write directly to console from PSCmdlet? I need to circumvent all redirections.

[dkaszews]

Stole the code from Write-Host, tested it to work

[PaulHigin]

Removing WG-Remoting tag since this does not involve PowerShell remoting.

[ghost]

:tada:This issue was addressed in #18222, which has now been successfully released as v7.4.0-preview.4.:tada:

Handy links:

• Release Notes