mosh does not transmit OSC 52 sequence to client

[sunaku]

Similar to #549 and #552, this limitation prevents me from copying text from remote shell sessions into my local terminal via the OSC 52 escape sequence. It's also the reason I still use SSH instead of Mosh. 😱

I tried to patch this but got stuck. 😢 Any hints on how to write a string to the raw terminal device?

diff --git a/src/terminal/terminalfunctions.cc b/src/terminal/terminalfunctions.cc
index 35c8055..1983aec 100644
--- a/src/terminal/terminalfunctions.cc
+++ b/src/terminal/terminalfunctions.cc
@@ -558,6 +558,46 @@ void Dispatcher::OSC_dispatch( const Parser::OSC_End *act, Framebuffer *fb )
        * 2: set window title */
       cmd_num = OSC_string[ 0 ] - L'0';
       offset = 2;
+    } else if ( (OSC_string.size() >= 3) && (OSC_string[ 2 ] == L';') ) {
+      /* OSC of the form "\033]XX;<Pt>\007" where XX can be:
+       * 10: Change VT100 text foreground color to Pt.
+       * 11: Change VT100 text background color to Pt.
+       * 12: Change text cursor color to Pt.
+       * 13: Change mouse foreground color to Pt.
+       * 14: Change mouse background color to Pt.
+       * 15: Change Tektronix foreground color to Pt.
+       * 16: Change Tektronix background color to Pt.
+       * 17: Change highlight background color to Pt.
+       * 18: Change Tektronix cursor color to Pt.
+       * 19: Change highlight foreground color to Pt.
+       * 46: Change Log File to Pt.  (This is normally disabled by a compile-time option).
+       * 50: Set Font to Pt.
+       * 51: reserved for Emacs shell.
+       * 52: Manipulate Selection Data.
+       */
+      cmd_num = 10 * (OSC_string[ 0 ] - L'0') +
+                     (OSC_string[ 1 ] - L'0');
+      offset = 3;
+    } else if ( (OSC_string.size() >= 4) && (OSC_string[ 3 ] == L';') ) {
+      /* OSC of the form "\033]XXX;<Pt>\007" where XXX can be:
+       * 104: Reset Color Number c.
+       * 105: Reset Special Color Number c.
+       * 106: Enable/disable Special Color Number c.
+       * 110: Reset VT100 text foreground color.
+       * 111: Reset VT100 text background color.
+       * 112: Reset text cursor color.
+       * 113: Reset mouse foreground color.
+       * 114: Reset mouse background color.
+       * 115: Reset Tektronix foreground color.
+       * 116: Reset Tektronix background color.
+       * 117: Reset highlight color.
+       * 118: Reset Tektronix cursor color.
+       * 119: Reset highlight foreground color.
+       */
+      cmd_num = 100 * (OSC_string[ 0 ] - L'0') +
+                 10 * (OSC_string[ 1 ] - L'0') +
+                      (OSC_string[ 2 ] - L'0');
+      offset = 4;
     }
     bool set_icon = (cmd_num == 0 || cmd_num == 1);
     bool set_title = (cmd_num == 0 || cmd_num == 2);
@@ -569,6 +609,9 @@ void Dispatcher::OSC_dispatch( const Parser::OSC_End *act, Framebuffer *fb )

       act->handled = true;
     }
+    else {
+      // HELP ME: how can I write the OSC_string as-is to the terminal device?
+    }
   }
 }

[vdrandom]

(I'm not really sure if it's the right place, but another issue is a couple of years old with no news: #352, and this seems related.)
Maybe support cursor shape change escapes as well:

\033[X \007
or
\e[X q

where X indicates the shape of the text cursor
EDIT: I personally have no experience with C++, so I probably cannot help with that.
Also tmux somehow manages to change the shape and color of the cursor even during mosh session in command mode (^B, :).

[acornejo]

This also causes problems with the mosh chrome extension, since the only way to access the clipboard from within a chrome terminal is through these escape sequences (xclip, pbcopy, etc.. don't really work inside chrome)

[agriffis]

Was this fixed by #899?

[andersk]

@agriffis That’s the theory. It’s not in a released version yet; you’ll need both a server and a client from Git.

I haven’t tested it myself, but looking at the implementation, I’m worried it’s probably buggy, so I’m going to leave this open for now.

1. It only handles the specific sequence OSC 5 2 ; c ; base-64-data (BEL|ST), so it does not handle clipboard types other than the system clipboard (see the specification).
2. It does not pass on the sequence if it’s the same as the last such sequence passed on, so you can’t copy the same string twice in a row (even if there was an intervening copy in another application), or paste twice in a row.

[agriffis]

you’ll need both a server and a client from Git

As it happens, I have that ;-)

https://copr.fedorainfracloud.org/coprs/agriffis/mosh-nightly/

does not handle clipboard types other than the system clipboard

Hard to tell if that matters. primary, select, cut buffers are all relics of X11. Although I don't know why mosh wouldn't just pass that parameter through.

can’t copy the same string twice in a row

Ugh, yes, I see that. (just tested)

[andersk]

Hard to tell if that matters. primary, select, cut buffers are all relics of X11. Although I don't know why mosh wouldn't just pass that parameter through.

Well, some of us still use X11, but more to the point, the clipboard type is specified as a set of zero or more characters from cps01234567, so it could have c and also something else.

can’t copy the same string twice in a row

Ugh, yes, I see that. (just tested)

Thanks for the testing.

[gwicke]

#1054 has more liberal OSC 52 option parsing, which makes clipboard updates work with tmux among others. The custom options are not preserved across the connection at this point, but at least it does update the clipboard, without a need for tweaking tmux & co to conform to mosh.

[dohsimpson]

#899 fixed it for me. My set up using iTerm2 + mosh + tmux. iTerm2 needs "Allow clipboard access to terminal apps" enabled.

You need to build both the client and the server. And restart your mosh session.

e.g. my mosh version: mosh 1.3.2 [build b1da700]

FYI, use this command to test clipboard works. This should put "blabla" in your Mac's clipboard.

printf "\033]52;c;$(printf "%s" "blabla" | base64)\a" (credit)

[mpercy]

@dohsimpson I am running mosh 1.3.2 (macOS client, Linux server) and the above printf does not copy to my client's system clipboard when using mosh (it works over plain ssh).

Edit: I just realized that mosh 1.3.2 was released in 2017 and you have commented here in 2019, so I suppose you just cherry-picked #899 on top of 1.3.2 and rolled your own build. Your comment referring to version 1.3.2 as working was confusing to me, since the 1.3.2 release does not have this feature.

[ScottRochford]

It would be really good if this fix made it into the mainstream release, which seems long overdue - is something blocking it?

[NightMachinery]

This makes mosh not work with kitty's clipboard as well: kovidgoyal/kitty#1558

[greened]

I need something very similar to the patch posted in the first comment of this issue, for emacs directory tracking (OSC 51). I think I just need to pass the OSC to the terminal but like @sunaku I'm not sure how to do that.

See #1122.

[rcorre]

#899 did not fix it for me. With a Mac client (using kitty terminal) and Linux server both running mosh-1.3.2-105-gdbe419d (built from source), OSC yank works over a raw ssh session but not mosh.

I tried #1054 and that fixed it for me.