[SOLVED] ssh set clipboard of remote machine

Yann · 2020-11-26 18:48:29

Hi everyone,

I would like to set the clipboard of a remote ssh server machine through ssh. For example, I have machine A (MA) and machine B (MB), I would like to run a ssh command from MA to set the X clipboard of MB.

When I connect to MB from MA and run a xclip command I get:

$ echo -n "TEST" |  xclip -selection clipboard -i
Error: Can't open display: (null)

However, if I set the DISPLAY environnement variable it works

$ export DISPLAY=:0
$ echo -n "TEST" |  xclip -selection clipboard -i

I would like to do that automatically. What command would do it ?

I tried

$ ssh MB 'echo -n TEST |  xclip -selection clipboard -i'
X11 forwarding request failed on channel 0
Error: Can't open display: (null)

and

$ ssh MB 'export DISPLAY=:0;echo -n TEST |  xclip -selection clipboard -i'
X11 forwarding request failed on channel 0

This last command works but doesn't return the prompt and I have to SIGKILL it. Any idea how to terminate the command and not having a process waiting ?

Thanks for your time.

Last edited by Yann (2020-11-27 11:24:19)

seth · 2020-11-26 22:14:59

This last command works but doesn't return the prompt and I have to SIGKILL it.

"man xclip", you can use "-l1", but the client *has* to run to allow the paste.

The content is not buffered on the server, but in xclip - once you request it (paste it), xclip provides the data to the pasting client.
https://wiki.archlinux.org/index.php/Clipboard and sublinks

Last edited by seth (2020-11-26 22:15:11)

Trilby · 2020-11-26 22:54:51

I don't use xclip, but xsel works fine remotely for me:

echo some stuff here | ssh $server 'DISPLAY=:1 xsel -i'

(adjust the DISPLAY value as needed, yours might more likely be :0)

seth · 2020-11-27 07:16:38

xsel auto-forks

Yann · 2020-11-27 11:24:01

xsel does the trick. These two commands work and return the prompt.

echo -n TEST | ssh MB 'export DISPLAY=:0; xsel --clipboard -i'

ssh MB 'export DISPLAY=:0;echo -n TEST | xsel --clipboard -i'

I don't understand the difference of behavior. The --loop option seems indeed to talk about that:

with a value of 0 (default) causing xclip to wait for an unlimited number of requests until another application (possibly another invocation of xclip) takes ownership of the selection

However, I tried -l 1 and didn't see lots of changes. It might not be that important that I understand that part.

Thanks for the help !!

seth · 2020-11-27 12:43:41

"xclip -l1" will keep the xclip process running until you paste the selection somewhere (once), -l2 allows two pastes etcetc.
xsel just immediately forks and continues to run in the background to feed the selection buffer.

Yann · 2020-11-27 14:44:59

Got it. I took a time to study the X clipboard fonctionnement. I did not expect that.

xclip or xsel are X processes without X windows. When using them to set the clipboard, they are just X windows owning the clipboard in their own buffer. When another X application needs to past, the X server will call a specific function of the X application owning the clipboard to send the application buffer content containing the copy to the stdin of the pasting X application.

Why not having this buffer in the X server directly? This forces every X application to have the necessary functions to support this feature. Also, when closing the X application owning the clipboard, it is gone.

I could see the -loop X argument in action, when X pasts are done, the xclip process gets killed and there is no more clipboard available.

seth · 2020-11-27 15:02:43

"Why is/does/cannot X11": https://en.wikipedia.org/wiki/X_Window_System#History
Moving the data to the server can be rather expensive if there's much data, a remote server and 1987… ;-)

There're several clipboard manager client implementations, though. (ie. background processes that immediately store the clipboard content)

Trilby · 2020-11-27 15:04:54

Yann wrote:

This forces every X application to have the necessary functions to support this feature.

False. Only programs that intend to interact "copy" or "cut" data to a selction need these functions, and the functions are in fact quite simple; or at least they can be, some programs may have elaborate versions, but the basic requirements are trivial.

Yann wrote:

Also, when closing the X application owning the clipboard, it is gone.

This is true. And this is one of the primary motivations of selection managers to close this gap.

Yann wrote:

Why not having this buffer in the X server directly?

Because it is not known ahead of time how big the selection data might be. Selections are often short text strings, but they can be anything including images, or arbitrarily large binary blob data. If the X server were to own this data the server would either have to start with a very large static data space - which still might occasionally be too small, or it'd have to dynamically allocate space as needed.

Far more importantly than this, though, is that X was designed as a network protocol. Under the original design the client and server were often not the same machine - and it still can be used this way even if many of us now have them both on the same physical machine. If the server were to store selection data, then anytime an image program copied image data to a selection, it'd have to send that data over the network. Then every time another client pasted the image, it would retrieve all that data over the network. Despite the sender and receiver being on the same physical machine, the data would have to be sent to another machine and back. This is very bad design. This is compounded by the fact that every time there was a copy operation, the data would have to be sent, whether or not any client would ever request it for pasting.

Contrast this with the design that was chosen: an image program copies large image data and all that is sent to the server is a very short message saying "I've copied something". Then when another client program requests a paste, all the xserver sends back is the id of the selection owner. The pasting client contacts the copy client and the data is transferred directly from client to client on the same machine.

This was a very good design choice by the X11 developers.

Yann · 2020-11-27 15:30:30

Very very clear ! Indeed, it makes lots of sens to do it that way.

33 years old X11, begins to have some experiences.

Thanks a lots for all these great responses. This is very appreciable.

Arch Linux

#1 2020-11-26 18:48:29

[SOLVED] ssh set clipboard of remote machine

#2 2020-11-26 22:14:59

Re: [SOLVED] ssh set clipboard of remote machine

#3 2020-11-26 22:54:51

Re: [SOLVED] ssh set clipboard of remote machine

#4 2020-11-27 07:16:38

Re: [SOLVED] ssh set clipboard of remote machine

#5 2020-11-27 11:24:01

Re: [SOLVED] ssh set clipboard of remote machine

#6 2020-11-27 12:43:41

Re: [SOLVED] ssh set clipboard of remote machine

#7 2020-11-27 14:44:59

Re: [SOLVED] ssh set clipboard of remote machine

#8 2020-11-27 15:02:43

Re: [SOLVED] ssh set clipboard of remote machine

#9 2020-11-27 15:04:54

Re: [SOLVED] ssh set clipboard of remote machine

#10 2020-11-27 15:30:30

Re: [SOLVED] ssh set clipboard of remote machine

Board footer