tmux copy buffer is not transferred to clipboard. #967
Comments
|
Can you confirm that you have the latest version of mosh on both the client and the server? |
|
I can confirm |
|
See same mosh client 1.3.2 (linux mosh 1.3.2 and macOS/iTerm) |
|
Same issue here on iTerm2 using mosh 1.3.2 (via macports) on client and server, macOS Mojave on both ends. If I ssh and send the below, "blah" is placed on my local clipboard. UPDATE: UPDATE 2: |
|
This patch to mosh made tmux clipboard updates work for me out of the box: #1054 |
|
From Mac OSX (Mojave) - from iterm2 - initiated "mosh [email protected] -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 |
|
I got the same issue as sravan1611 |
mgulick
added a commit
to mgulick/mosh
that referenced
this issue
Jul 23, 2020
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.
Mic92
pushed a commit
to Mic92/mosh
that referenced
this issue
Aug 13, 2021
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.
jlangston
pushed a commit
to jlangston/mosh
that referenced
this issue
Dec 28, 2021
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.
kam1kaze
pushed a commit
to kam1kaze/mosh-static
that referenced
this issue
Jan 25, 2022
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.
Mic92
pushed a commit
to Mic92/mosh
that referenced
this issue
Jan 30, 2022
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.
nikkon-dev
pushed a commit
to nikkon-dev/mosh
that referenced
this issue
Feb 10, 2022
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.
denizevrenci
pushed a commit
to denizevrenci/mosh
that referenced
this issue
Oct 2, 2022
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.
mgulick
added a commit
to mgulick/mosh
that referenced
this issue
Jan 6, 2024
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.
MaxGyver83
pushed a commit
to MaxGyver83/mosh
that referenced
this issue
Jun 5, 2024
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.
Part 2
======
Instead of using the contents of the clipboard to determine if the
user has copied any text, use a sequence number that is updated
whenever text is copied. Consider the following scenario (as
described in mobile-shell#1090):
1. User copies text 'abc' on remote machine via mosh.
2. User copies text 'xyz' on local machine.
3. User copies text 'abc' on remote machine again.
The local clipboard will still has 'xyz' because the most recent copy
text 'abc' matches the last text copied via mosh, so it does not
detect that the user copied new text and does not update the local
clipboard.
This patch updates detection of newly copied text via a sequence
number. This number is an 8-bit unsigned integer that is updated
every time new text is copied. This will roll over after 256
clipboard updates, but that is fine as we only care about it being
different than the last value.
Fixes mobile-shell#1090.
Fixes mobile-shell#637.
msva
pushed a commit
to alphallc/mosh
that referenced
this issue
Jun 16, 2024
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm having exact the same problem which @alexbozhenko mentioned here.
#899 (comment)
And, I think the issue was resolved with the pull request.
But I'm still having the same problem.
I tested the recent master branch on iterm 2 and MacOS 10.13.3.
The text was updated successfully, but these errors were encountered: