Skip to content

Commit

Permalink
Support additional OSC 52 clipboard types
Browse files Browse the repository at this point in the history
The OSC 52 escape sequence supports specifying which X selection
buffer place to the selection into.  The protocol format is:

  \033]52;C;D\007

The C parameter determines the selection buffer.  It consists of zero
or more of the following characters:

 c: CLIPBOARD
 p: PRIMARY
 q: SECONDARY
 s: XTerm-selected (based on XTerm.vt100.selectToClipboard)
 0-7: Numbered cut buffer

The default if left blank is 's0', representing the configurable
primary/clipboard selection and cut buffer 0. [1]

D is the base64 encoded text to place in the selection buffer.

This patch modifies the transferred clipboard data to include both the
selection parameter and the base64 text.  I.e. previously the
transferred clipboard data only contained 'D', and now it contains
'C;D'.

To test this functionality:

  1. Open XTerm
  2. Ctrl-Right Click and select 'Allow Window Ops'
  3. Connect to a server w/ mosh
  4. Run the following in the remote connection:
     $ printf "\033]52;c;$(echo test1234 | base64)\007"
     $ printf "\033]52;p;$(echo test2345 | base64)\007"
     $ printf "\033]52;q;$(echo test3456 | base64)\007"
  6. Open another terminal on the local machine and run:
     $ xclip -o -selection clipboard
     test1234
     $ xclip -o -selection primary
     test2345
     $ xclip -o -selection secondary
     test3456
  7. You can also try:
     $ printf "\033]52;;$(echo testdefault | base64)\007"
     (This should update either the clipboard or primary selection
     based on the Xterm settings)
  8. To test the cut buffers you can use the same
     procedure, substituting the cut buffer number in C, and then use
     'xcutsel' to transfer the data from the cut buffer to the PRIMARY
     selection, where it can then be viewed with 'xclip'.

Note, I observed that XTerm does not currently (as of XTerm patch 358)
support specifying more than one value in C.  The specification does
support it, and this appears to just be a simple bug in XTerm (a patch
has been submitted to the maintainer to fix it).

[1] https://github.com/ThomasDickey/xterm-snapshots/blob/master/ctlseqs.txt

Fixes mobile-shell#967.
  • Loading branch information
mgulick authored and Jeff Langston committed Dec 28, 2021
1 parent 378dfa6 commit 387b396
Show file tree
Hide file tree
Showing 2 changed files with 8 additions and 5 deletions.
2 changes: 1 addition & 1 deletion src/terminal/terminaldisplay.cc
Original file line number Diff line number Diff line change
Expand Up @@ -112,7 +112,7 @@ std::string Display::new_frame( bool initialized, const Framebuffer &last, const

/* has clipboard changed? */
if (f.get_clipboard() != frame.last_frame.get_clipboard()) {
frame.append( "\033]52;c;" );
frame.append( "\033]52;" );
const title_type &clipboard( f.get_clipboard() );
for ( title_type::const_iterator i = clipboard.begin();
i != clipboard.end();
Expand Down
11 changes: 7 additions & 4 deletions src/terminal/terminalfunctions.cc
Original file line number Diff line number Diff line change
Expand Up @@ -591,12 +591,15 @@ static Function func_CSI_DECSTR( CSI, "!p", CSI_DECSTR );
/* xterm uses an Operating System Command to set the window title */
void Dispatcher::OSC_dispatch( const Parser::OSC_End *act __attribute((unused)), Framebuffer *fb )
{
/* handle osc copy clipboard sequence 52;c; */
/* Handle OSC copy clipboard sequence 52;c; and variants */
if ( OSC_string.size() >= 5 && OSC_string[ 0 ] == L'5' &&
OSC_string[ 1 ] == L'2' && OSC_string[ 2 ] == L';' &&
OSC_string[ 3 ] == L'c' && OSC_string[ 4 ] == L';') {
OSC_string[ 1 ] == L'2' && OSC_string[ 2 ] == L';') {
/* Capture the options and clipboard contents
e.g. '52;c;bW9zaCBpcyBncmVhdAo='
^^^^^^^^^^^^^^^^^^^^^^^
capture this part */
Terminal::Framebuffer::title_type clipboard(
OSC_string.begin() + 5, OSC_string.end() );
OSC_string.begin() + 3, OSC_string.end() );
fb->set_clipboard( clipboard );
/* handle osc terminal title sequence */
} else if ( OSC_string.size() >= 1 ) {
Expand Down

0 comments on commit 387b396

Please sign in to comment.