Support OSC 52 clipboard updates from tmux & others

[gwicke]

Be more liberal in which options mosh accepts in clipboard updates, even
if those options are not preserved across the connection at this point.
This includes clipboard updates emitted by tmux, which is very
frequently used with mosh.

This eliminates the need for work-arounds like
https://gist.github.com/yudai/95b20e3da66df1b066531997f982b57b, which
did not even work for me.

[stlava]

Hoping this can be merged in soon. The work around isn't working for us either.

[jdelman]

@gwicke I just built this from source and copying still isn't working as I expect - are you able to do it with a simple mouse highlight with set -g mouse on? Any special terminal escapes needed?

[gwicke]

@jdelman, did you rebuild both ends of the connection?

For me this works with regular mouse highlights in tmux, as well as printf "\033]52;c;$(printf "%s" "blabla" | base64)\a" in a plain mosh shell. The main remaining limitation in mosh is that the copy buffer is size limited to a single UDP packet. In practice, copied text is truncated when it exceeds the size of one packet.

[jdelman]

Ah, I only did the server - I will rebuild the client as well and let you know, thanks. On September 26, 2019 at 12:37:55 PM, Gabriel Wicke ( notifications@github.com) wrote: @jdelman <https://github.com/jdelman>, did you rebuild both ends of the connection? For me this works with regular mouse highlights in tmux, as well as printf "\033]52;c;$(printf "%s" "blabla" | base64)\a" in a plain mosh shell. The main remaining limitation in mosh is that the copy buffer is size limited to a single UDP packet. In practice, copied text is truncated when it exceeds the size of one packet. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1054?email_source=notifications&email_token=AAVPMLM2RO4I7DCQVET7DELQLTQOHA5CNFSM4IEKZWW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7WGK6Y#issuecomment-535586171>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAVPMLPNRYATX6SOBZ4PPODQLTQOHANCNFSM4IEKZWWQ> .

[jdelman]

@gwicke It's working - thanks so much.

[dvn0]

Friendly bump on this. Would love to see OSC 52 support in Mosh

[fanktom]

I have build both client and server from master and it works if I run "\033]52;c;$(printf "%s" "blabla" | base64)\a" from a plain mosh shell. If I do the same from a tmux session it does not work.

Is there still any work (special copy symbols, etc.) needed on the tmux side?

Thanks for your help!

Client (Mac OSX):
mosh -v
mosh 1.3.2 [build mosh-1.3.2-86-g0cc492d-dirty]

Server (Debian):
mosh -v
mosh 1.3.2 [build mosh-1.3.2-86-g0cc492d]

[sunaku]

You need to escape your sequence one more time for tmux:

esc="\033]52;c;$(printf %s "blabla" | base64)\a"
esc="\033Ptmux;\033$esc\033\\" # again for tmux!
printf "$esc"

See also https://sunaku.github.io/tmux-yank-osc52.html

[fanktom]

Thanks for the heads up. With this and parts from https://github.com/samoshkin/tmux-config/blob/master/tmux/yank.sh it worked perfectly.

[gwicke]

I am using this with native tmux clipboard support enabled in ~/.tmux.conf:

set -g set-clipboard on
set -g mouse on

With these two settings, both explicit tmux copy mode selections and mouse selections (up to a few hundred bytes) are copied to the clipboard via the mosh connection.

[sravan1611]

From Mac OSX (Mojave) - from iterm2 - initiated "mosh root@x.x.x.x -p 60001" to my remote linux server.

I have mosh 1.3.2 installed. And running tmux 3.0a on my remote server. With that I am not able to copy tmux buffer to osx clipboard.

If I do ssh instead of mosh, tmux buffer is getting copied to OSX clipboard. Attached my tmux config here.

Masters need your inputs

tmuxconf.txt

[gwicke]

@sravan1611, you need mosh builds including this diff on both the client & server. After that, tmux copying should work the same way it does on SSH, except that copy buffer sizes are limited to what fits into a single UDP packet.

[jianhuiz]

Works perfectly, thanks and hope this can get merged soon

[andrewmzhang]

I accidentally made a pull request that was a verbatim copy of this PR with the same name and code. The travis tests for this PR are now linked to the duplicate PR I made. I apologize for screwing this up.

I think the travis tests for my duplicate PR are failing since OSX is not building correctly due to homebrew problems. Thus if this PR is travis checked again it may fail due to the same build problems.

[varung]

when will this be merged? And after that, how long till it will be available in brew? If there is some way to help push this along, can someone post what that is? Thank you!

[mgulick]

Hey, so I just created a pull request which (I think) supersedes this one. The issue I was having when I tested this PR (on Linux w/ XTerm) was that my copied text always went into the CLIPBOARD, whereas with SSH it would go into the PRIMARY selection. This new PR #1104 preserves the parameter in the OSC52 escape sequence which specifies which selection to put the copied text into.

[asanakoy]

Any updates on this? I would also love to have this feature in mosh.

[catskul]

Can someone with permission re-trigger the CI on this? Looks like the last time it ran was >3yrs ago so the log is gone by now.

[achernya]

I think the PR needs to be re-pushed. I don't see a way to re-run the CI since we moved from Travis to Github Actions in the meantime.

[catskul]

Hm. @gwicke could you re-push this branch?

[mgulick]

@achernya, any interest in merging #1104 instead? When I implemented it, I looked into the OSC 52 protocol in detail and I think that MR handles all cases. More details in https://www.xfree86.org/current/ctlseqs.html. The only thing I'm not sure about is if is compatible between mis-matched server/client versions (i.e. those with and without the patch). I could probably try to make it work if that is a concern.

This patch, #1054, doesn't preserve the OSC52 type (i.e. clipboard, primary, select, cut buffers 0-7), so the xterm on the other side always stuffs the selection into the clipboard, rather than the original destination. #1104 does this, and fixes a few other things as well.

[achernya]

@mgulick I'll have to deep-dive both PRs to be able to make an educated assessment. Based on your description, yes, I'm interested, post 1.4 release. (I need to go make sure the Debian packages build now that we've identified and worked through the tmux issue)

[willdumm]

Although mosh 1.4.0 claims to support OSC52 copy, it still doesn't seem to work with tmux.

By "copy works" I mean that running printf "\033]52;c;$(printf "%s" "hello" | base64)\a" in a terminal that supports OSC 52 copy (for me, iTerm2) sets the local clipboard contents to hello.
My local machine and server A are both running mosh 1.4.0.
tmux server A and B is version 2.6, with set -g set-clipboard on in tmux.conf.

1. Connected via mosh (both mosh client and server v1.4.0), copy works.
2. Connected via mosh, but running tmux on remote, copy doesn't work.
3. Connected via mosh to bastion host (server A), then via ssh to another server (server B), copy doesn't work.
4. Connected via mosh to bastion host (server A), then via ssh to another server (server B), and running tmux on server B, copy doesn't work.
5. Any of 1-4, but replacing mosh with ssh, copy works.

However, adding
set-option -ag terminal-overrides ",xterm-256color:Ms=\\E]52;c;%p2%s\\7" to tmux.conf may fix (2) and (4) on tmux 3.3 but not 2.6? I need to experiment more with this.
(suggestion from here: https://rdzhou.github.io/2018/05/23/tmux-with-mosh/)

EDIT:
Indeed, using tmux v3.3a and putting

set-option -ag terminal-overrides ",xterm-256color:Ms=\\E]52;c;%p2%s\\7"

in tmux.conf, solves (2) and (4), while still allowing copy to work when using tmux over plain ssh.
(3) is not solved, but outside the context of tmux, native terminal copy works fine
This seems to be a perfect workaround, if you have the freedom to run a recent enough version of tmux. It would be nice if no workaround was necessary, but it's still exciting to get this feature on mosh!

[riordant]

Although mosh 1.4.0 claims to support OSC52 copy, it still doesn't seem to work with tmux.

By "copy works" I mean that running printf "\033]52;c;$(printf "%s" "hello" | base64)\a" in a terminal that supports OSC 52 copy (for me, iTerm2) sets the local clipboard contents to hello. My local machine and server A are both running mosh 1.4.0. tmux server A and B is version 2.6, with set -g set-clipboard on in tmux.conf.

1. Connected via mosh (both mosh client and server v1.4.0), copy works.
2. Connected via mosh, but running tmux on remote, copy doesn't work.
3. Connected via mosh to bastion host (server A), then via ssh to another server (server B), copy doesn't work.
4. Connected via mosh to bastion host (server A), then via ssh to another server (server B), and running tmux on server B, copy doesn't work.
5. Any of 1-4, but replacing mosh with ssh, copy works.

However, adding set-option -ag terminal-overrides ",xterm-256color:Ms=\\E]52;c;%p2%s\\7" to tmux.conf may fix (2) and (4) on tmux 3.3 but not 2.6? I need to experiment more with this. (suggestion from here: https://rdzhou.github.io/2018/05/23/tmux-with-mosh/)

EDIT: Indeed, using tmux v3.3a and putting

set-option -ag terminal-overrides ",xterm-256color:Ms=\\E]52;c;%p2%s\\7"

in tmux.conf, solves (2) and (4), while still allowing copy to work when using tmux over plain ssh. (3) is not solved, but outside the context of tmux, native terminal copy works fine This seems to be a perfect workaround, if you have the freedom to run a recent enough version of tmux. It would be nice if no workaround was necessary, but it's still exciting to get this feature on mosh!

Exactly what I needed, thank you so much!

[cosmojg]

Although mosh 1.4.0 claims to support OSC52 copy, it still doesn't seem to work with tmux.

By "copy works" I mean that running printf "\033]52;c;$(printf "%s" "hello" | base64)\a" in a terminal that supports OSC 52 copy (for me, iTerm2) sets the local clipboard contents to hello. My local machine and server A are both running mosh 1.4.0. tmux server A and B is version 2.6, with set -g set-clipboard on in tmux.conf.

1. Connected via mosh (both mosh client and server v1.4.0), copy works.
2. Connected via mosh, but running tmux on remote, copy doesn't work.
3. Connected via mosh to bastion host (server A), then via ssh to another server (server B), copy doesn't work.
4. Connected via mosh to bastion host (server A), then via ssh to another server (server B), and running tmux on server B, copy doesn't work.
5. Any of 1-4, but replacing mosh with ssh, copy works.

However, adding set-option -ag terminal-overrides ",xterm-256color:Ms=\\E]52;c;%p2%s\\7" to tmux.conf may fix (2) and (4) on tmux 3.3 but not 2.6? I need to experiment more with this. (suggestion from here: https://rdzhou.github.io/2018/05/23/tmux-with-mosh/)

EDIT: Indeed, using tmux v3.3a and putting

set-option -ag terminal-overrides ",xterm-256color:Ms=\\E]52;c;%p2%s\\7"

in tmux.conf, solves (2) and (4), while still allowing copy to work when using tmux over plain ssh. (3) is not solved, but outside the context of tmux, native terminal copy works fine This seems to be a perfect workaround, if you have the freedom to run a recent enough version of tmux. It would be nice if no workaround was necessary, but it's still exciting to get this feature on mosh!

Hmm, this workaround stopped working for me all of a sudden. I'm running mosh 1.4.0 on both the client and the server, and I'm running tmux 3.3a on the server. The clipboard works just fine with mosh on its own and with tmux via ssh, but as before, tmux via mosh breaks the clipboard.

Notably, the above terminal-overrides option breaks the clipboard for tmux via ssh as well. Maybe something changed on the tmux side?

[catskul]

iTerm2 just updated. I wonder if that has something to do with it.

[IamGianluca]

Updating mosh to 1.4.0 (both local and server-side) and tmux to 3.3a, plus the changes listed below to the tmux.conf file as suggested by @willdumm worked for me.

set -g set-clipboard on
set-option -ag terminal-overrides ",xterm-256color:Ms=\\E]52;c;%p2%s\\7"

The curious thing is that my TERM is screen-256color, not xterm-256color.

[mellery451]

word of warning - I think tmux 3.4 might have broken something because I can't get it work at all (osc52 through tmux + mosh). I've eliminated mosh by testing without tmux and Tmux version just recently updated so that's what I suspect. tmux/tmux#3964 seems possibly involved.

UPDATE - did some more testing and I think for tmux 3.4 you don't want the terminal overrides above. YMMV

[arg]

This works for me:

Local system

[I] ~$ sw_vers
ProductName:		macOS
ProductVersion:		14.4.1
BuildVersion:		23E224

[I] ~$ mosh -v
mosh 1.4.0 [build mosh 1.4.0]

Remote system

[I] ~$ freebsd-version                                                                                                                                                                           
14.0-RELEASE-p6

[I] ~$ mosh -v                                                                                                                                                                                   
mosh 1.4.0 [build mosh 1.4.0]

[I] ~$ tmux -V                                                                                                                                                                                   
tmux 3.3a

tmux.conf

set -ag terminal-overrides ",screen-256color:colors=256:Tc:Ms=\\E]52;c;%p2%s\\7"
set -g set-clipboard on

Clipboard works in both Tmux (yank in Vim mode) and Neovim (running in Tmux session with nvim-osc52 plugin). However the remote Tmux is 3.3, not 3.4. Clipboard in local 3.4 also works fine (I assume it's because of set-clipboard option).

Also to note, I connect to the remote directly (mosh <server name), not through bastion host.