Skip to content
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

Set-Clipboard -Remote with OSC52 #18116

Open
dkaszews opened this issue Sep 17, 2022 · 7 comments · May be fixed by #18222
Open

Set-Clipboard -Remote with OSC52 #18116

dkaszews opened this issue Sep 17, 2022 · 7 comments · May be fixed by #18222
Labels
Hacktoberfest Potential candidate to participate in Hacktoberfest In-PR Indicates that a PR is out for the issue Issue-Enhancement the issue is more of a feature request than a bug Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors WG-Cmdlets general cmdlet issues

Comments

@dkaszews
Copy link
Contributor

dkaszews commented Sep 17, 2022

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.

@dkaszews dkaszews added Issue-Enhancement the issue is more of a feature request than a bug Needs-Triage The issue is new and needs to be triaged by a work group. labels Sep 17, 2022
@237dmitry
Copy link

237dmitry commented Sep 17, 2022

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
Copy link

jhoneill commented Sep 17, 2022

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 #18098 (comment) ) . 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
Copy link
Contributor Author

dkaszews commented Sep 17, 2022

@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 SteveL-MSFT added WG-Remoting PSRP issues with any transport layer WG-Cmdlets general cmdlet issues labels Sep 26, 2022
@SteveL-MSFT
Copy link
Member

SteveL-MSFT commented Oct 5, 2022

@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.

@SteveL-MSFT SteveL-MSFT added Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors Hacktoberfest Potential candidate to participate in Hacktoberfest and removed Needs-Triage The issue is new and needs to be triaged by a work group. labels Oct 5, 2022
@dkaszews
Copy link
Contributor Author

dkaszews commented Oct 5, 2022

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
Copy link
Contributor Author

dkaszews commented Oct 5, 2022

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

@dkaszews dkaszews linked a pull request Oct 5, 2022 that will close this issue
22 tasks
@msftbot msftbot bot added the In-PR Indicates that a PR is out for the issue label Oct 5, 2022
@PaulHigin
Copy link
Collaborator

PaulHigin commented Nov 14, 2022

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

@PaulHigin PaulHigin removed the WG-Remoting PSRP issues with any transport layer label Nov 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Hacktoberfest Potential candidate to participate in Hacktoberfest In-PR Indicates that a PR is out for the issue Issue-Enhancement the issue is more of a feature request than a bug Up-for-Grabs Up-for-grabs issues are not high priorities, and may be opportunities for external contributors WG-Cmdlets general cmdlet issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants