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
Comments
|
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? |
|
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
I'm guessing the latter is preferred but the former is mostly harmless. |
|
@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. |
|
@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. |
|
I'm working on implementation, got stuck on a stupid issue - how do I write directly to console from |
|
Stole the code from |
|
Removing WG-Remoting tag since this does not involve PowerShell remoting. |
dkaszews commentedSep 17, 2022
Summary of the new feature / enhancement
Set-Clipboarddoes 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, thenSet-Clipboardwill 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:
OSC also has similar
Get-Clipboard -Remotesequence, 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:
$env:SSH_CLIENTand$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_TTYto their$PROFILE.set -s set-clipboard on. I would say keep it simple for now, then maybe add-RemoteMethod = auto | osc52 | tmux | screenin separate issue if required.Proposed technical implementation details (optional)
See example for the escape sequence format.
The text was updated successfully, but these errors were encountered: