How do command line clipboard tools like “xclip” and “xsel” persist the clipboard - in a X windows...
After reading this question about the X clipboard getting cleared when vim is exited I learned that the X window clipboard only exists while the program - from which the selection was obtained - remains open.
It is because of this behaviour that programs like "glipper" and "parcellite" exist.
If the X clipboard is cleared every time a program is exited, how do programs like xclip and xsel work?
And what are the security implications of using programs like this? For example, if a password was copied to the clipboard, could this password be saved into some temp file that could be accessed by programs or users?
clipboard x-server
edited Feb 23 at 1:47
Jeff Schaller
43.4k1160140
asked Jun 2 '17 at 10:55
the_velour_fogthe_velour_fog
5,39243465
add a comment |
After reading this question about the X clipboard getting cleared when vim is exited I learned that the X window clipboard only exists while the program - from which the selection was obtained - remains open.
It is because of this behaviour that programs like "glipper" and "parcellite" exist.
If the X clipboard is cleared every time a program is exited, how do programs like xclip and xsel work?
And what are the security implications of using programs like this? For example, if a password was copied to the clipboard, could this password be saved into some temp file that could be accessed by programs or users?
clipboard x-server
edited Feb 23 at 1:47
Jeff Schaller
43.4k1160140
asked Jun 2 '17 at 10:55
the_velour_fogthe_velour_fog
5,39243465
add a comment |
After reading this question about the X clipboard getting cleared when vim is exited I learned that the X window clipboard only exists while the program - from which the selection was obtained - remains open.
It is because of this behaviour that programs like "glipper" and "parcellite" exist.
If the X clipboard is cleared every time a program is exited, how do programs like xclip and xsel work?
And what are the security implications of using programs like this? For example, if a password was copied to the clipboard, could this password be saved into some temp file that could be accessed by programs or users?
clipboard x-server
edited Feb 23 at 1:47
Jeff Schaller
43.4k1160140
asked Jun 2 '17 at 10:55
the_velour_fogthe_velour_fog
5,39243465
After reading this question about the X clipboard getting cleared when vim is exited I learned that the X window clipboard only exists while the program - from which the selection was obtained - remains open.
It is because of this behaviour that programs like "glipper" and "parcellite" exist.
If the X clipboard is cleared every time a program is exited, how do programs like xclip and xsel work?
And what are the security implications of using programs like this? For example, if a password was copied to the clipboard, could this password be saved into some temp file that could be accessed by programs or users?
clipboard x-server
clipboard x-server
edited Feb 23 at 1:47
Jeff Schaller
43.4k1160140
asked Jun 2 '17 at 10:55
the_velour_fogthe_velour_fog
5,39243465
edited Feb 23 at 1:47
Jeff Schaller
43.4k1160140
asked Jun 2 '17 at 10:55
the_velour_fogthe_velour_fog
5,39243465
edited Feb 23 at 1:47
Jeff Schaller
43.4k1160140
edited Feb 23 at 1:47
Jeff Schaller
43.4k1160140
edited Feb 23 at 1:47
Jeff Schaller
43.4k1160140
43.4k1160140
asked Jun 2 '17 at 10:55
the_velour_fogthe_velour_fog
5,39243465
asked Jun 2 '17 at 10:55
the_velour_fogthe_velour_fog
5,39243465
asked Jun 2 '17 at 10:55
the_velour_fogthe_velour_fog
5,39243465
5,39243465
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Unless there's a clipboard application like xclipboard, clipit... that steals the selections from them, xsel/xclip will fork a background process to handle the future selection requests as long as they own the selection.
$ printf test | xclip
$ ps -C xclip
PID TTY TIME CMD
14115 pts/10 00:00:00 xclip
That xclip process is handling requests for the selection (here PRIMARY selection). But, if you select something in another application (or use xsel or xclip again to store something else), then that xclip process will concede the selection to that other application and terminate.
$ printf test | xsel
$ ps -C xclip
PID TTY TIME CMD
$ ps -C xsel
PID TTY TIME CMD
14212 ? 00:00:00 xsel
Above, xsel took over the selection from xclip.
You can find out who owns a given selection with:
#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
int main(int argc, char* argv)
{
Display *d = XOpenDisplay(NULL);
Window w = XGetSelectionOwner(d, XInternAtom (d, argv[1], False));
printf("0x%08xn", w);
return 0;
}
Then:
$ make xgo LDFLAGS=-lX11
$ ./xgo PRIMARY
0x07000001
That will give you the window ID. You can use xprop -id or xwininfo -id on that id, but in the case of xclip/xsel, you won't get much information.
On GNU/Linux based systems, ltrace is useful to see what's happening at the X library API level.
See also Capture the X11 protocol's traffic to see what's happening at the X11 protocol level.
answered Jun 2 '17 at 13:13
Stéphane ChazelasStéphane Chazelas
309k57584945
thanks that explains it. yes a command likeps -efl --forestwill showxclipdisowned from its parent and re-attached higher up in the process tree similar to a daemon. Note to future readers who want to run this c code on ubuntu 16.04, I needed tosudo apt-get install libx11-dev, and compile withgcc -o clip clip.c -lX11to avoid make errors.
– the_velour_fog
Jun 3 '17 at 0:11
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f368775%2fhow-do-command-line-clipboard-tools-like-xclip-and-xsel-persist-the-clipboar%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Unless there's a clipboard application like xclipboard, clipit... that steals the selections from them, xsel/xclip will fork a background process to handle the future selection requests as long as they own the selection.
$ printf test | xclip
$ ps -C xclip
PID TTY TIME CMD
14115 pts/10 00:00:00 xclip
That xclip process is handling requests for the selection (here PRIMARY selection). But, if you select something in another application (or use xsel or xclip again to store something else), then that xclip process will concede the selection to that other application and terminate.
$ printf test | xsel
$ ps -C xclip
PID TTY TIME CMD
$ ps -C xsel
PID TTY TIME CMD
14212 ? 00:00:00 xsel
Above, xsel took over the selection from xclip.
You can find out who owns a given selection with:
#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
int main(int argc, char* argv)
{
Display *d = XOpenDisplay(NULL);
Window w = XGetSelectionOwner(d, XInternAtom (d, argv[1], False));
printf("0x%08xn", w);
return 0;
}
Then:
$ make xgo LDFLAGS=-lX11
$ ./xgo PRIMARY
0x07000001
That will give you the window ID. You can use xprop -id or xwininfo -id on that id, but in the case of xclip/xsel, you won't get much information.
On GNU/Linux based systems, ltrace is useful to see what's happening at the X library API level.
See also Capture the X11 protocol's traffic to see what's happening at the X11 protocol level.
answered Jun 2 '17 at 13:13
Stéphane ChazelasStéphane Chazelas
309k57584945
thanks that explains it. yes a command likeps -efl --forestwill showxclipdisowned from its parent and re-attached higher up in the process tree similar to a daemon. Note to future readers who want to run this c code on ubuntu 16.04, I needed tosudo apt-get install libx11-dev, and compile withgcc -o clip clip.c -lX11to avoid make errors.
– the_velour_fog
Jun 3 '17 at 0:11
add a comment |
Unless there's a clipboard application like xclipboard, clipit... that steals the selections from them, xsel/xclip will fork a background process to handle the future selection requests as long as they own the selection.
$ printf test | xclip
$ ps -C xclip
PID TTY TIME CMD
14115 pts/10 00:00:00 xclip
That xclip process is handling requests for the selection (here PRIMARY selection). But, if you select something in another application (or use xsel or xclip again to store something else), then that xclip process will concede the selection to that other application and terminate.
$ printf test | xsel
$ ps -C xclip
PID TTY TIME CMD
$ ps -C xsel
PID TTY TIME CMD
14212 ? 00:00:00 xsel
Above, xsel took over the selection from xclip.
You can find out who owns a given selection with:
#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
int main(int argc, char* argv)
{
Display *d = XOpenDisplay(NULL);
Window w = XGetSelectionOwner(d, XInternAtom (d, argv[1], False));
printf("0x%08xn", w);
return 0;
}
Then:
$ make xgo LDFLAGS=-lX11
$ ./xgo PRIMARY
0x07000001
That will give you the window ID. You can use xprop -id or xwininfo -id on that id, but in the case of xclip/xsel, you won't get much information.
On GNU/Linux based systems, ltrace is useful to see what's happening at the X library API level.
See also Capture the X11 protocol's traffic to see what's happening at the X11 protocol level.
answered Jun 2 '17 at 13:13
Stéphane ChazelasStéphane Chazelas
309k57584945
thanks that explains it. yes a command likeps -efl --forestwill showxclipdisowned from its parent and re-attached higher up in the process tree similar to a daemon. Note to future readers who want to run this c code on ubuntu 16.04, I needed tosudo apt-get install libx11-dev, and compile withgcc -o clip clip.c -lX11to avoid make errors.
– the_velour_fog
Jun 3 '17 at 0:11
add a comment |
Unless there's a clipboard application like xclipboard, clipit... that steals the selections from them, xsel/xclip will fork a background process to handle the future selection requests as long as they own the selection.
$ printf test | xclip
$ ps -C xclip
PID TTY TIME CMD
14115 pts/10 00:00:00 xclip
That xclip process is handling requests for the selection (here PRIMARY selection). But, if you select something in another application (or use xsel or xclip again to store something else), then that xclip process will concede the selection to that other application and terminate.
$ printf test | xsel
$ ps -C xclip
PID TTY TIME CMD
$ ps -C xsel
PID TTY TIME CMD
14212 ? 00:00:00 xsel
Above, xsel took over the selection from xclip.
You can find out who owns a given selection with:
#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
int main(int argc, char* argv)
{
Display *d = XOpenDisplay(NULL);
Window w = XGetSelectionOwner(d, XInternAtom (d, argv[1], False));
printf("0x%08xn", w);
return 0;
}
Then:
$ make xgo LDFLAGS=-lX11
$ ./xgo PRIMARY
0x07000001
That will give you the window ID. You can use xprop -id or xwininfo -id on that id, but in the case of xclip/xsel, you won't get much information.
On GNU/Linux based systems, ltrace is useful to see what's happening at the X library API level.
See also Capture the X11 protocol's traffic to see what's happening at the X11 protocol level.
answered Jun 2 '17 at 13:13
Stéphane ChazelasStéphane Chazelas
309k57584945
Unless there's a clipboard application like xclipboard, clipit... that steals the selections from them, xsel/xclip will fork a background process to handle the future selection requests as long as they own the selection.
$ printf test | xclip
$ ps -C xclip
PID TTY TIME CMD
14115 pts/10 00:00:00 xclip
That xclip process is handling requests for the selection (here PRIMARY selection). But, if you select something in another application (or use xsel or xclip again to store something else), then that xclip process will concede the selection to that other application and terminate.
$ printf test | xsel
$ ps -C xclip
PID TTY TIME CMD
$ ps -C xsel
PID TTY TIME CMD
14212 ? 00:00:00 xsel
Above, xsel took over the selection from xclip.
You can find out who owns a given selection with:
#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
int main(int argc, char* argv)
{
Display *d = XOpenDisplay(NULL);
Window w = XGetSelectionOwner(d, XInternAtom (d, argv[1], False));
printf("0x%08xn", w);
return 0;
}
Then:
$ make xgo LDFLAGS=-lX11
$ ./xgo PRIMARY
0x07000001
That will give you the window ID. You can use xprop -id or xwininfo -id on that id, but in the case of xclip/xsel, you won't get much information.
On GNU/Linux based systems, ltrace is useful to see what's happening at the X library API level.
See also Capture the X11 protocol's traffic to see what's happening at the X11 protocol level.
answered Jun 2 '17 at 13:13
Stéphane ChazelasStéphane Chazelas
309k57584945
edited Jun 2 '17 at 13:38
answered Jun 2 '17 at 13:13
Stéphane ChazelasStéphane Chazelas
309k57584945
answered Jun 2 '17 at 13:13
Stéphane ChazelasStéphane Chazelas
309k57584945
answered Jun 2 '17 at 13:13
Stéphane ChazelasStéphane Chazelas
309k57584945
309k57584945
thanks that explains it. yes a command likeps -efl --forestwill showxclipdisowned from its parent and re-attached higher up in the process tree similar to a daemon. Note to future readers who want to run this c code on ubuntu 16.04, I needed tosudo apt-get install libx11-dev, and compile withgcc -o clip clip.c -lX11to avoid make errors.
– the_velour_fog
Jun 3 '17 at 0:11
add a comment |
thanks that explains it. yes a command likeps -efl --forestwill showxclipdisowned from its parent and re-attached higher up in the process tree similar to a daemon. Note to future readers who want to run this c code on ubuntu 16.04, I needed tosudo apt-get install libx11-dev, and compile withgcc -o clip clip.c -lX11to avoid make errors.
– the_velour_fog
Jun 3 '17 at 0:11
thanks that explains it. yes a command like
ps -efl --forest will show xclip disowned from its parent and re-attached higher up in the process tree similar to a daemon. Note to future readers who want to run this c code on ubuntu 16.04, I needed to sudo apt-get install libx11-dev, and compile with gcc -o clip clip.c -lX11 to avoid make errors.– the_velour_fog
Jun 3 '17 at 0:11
thanks that explains it. yes a command like
ps -efl --forest will show xclip disowned from its parent and re-attached higher up in the process tree similar to a daemon. Note to future readers who want to run this c code on ubuntu 16.04, I needed to sudo apt-get install libx11-dev, and compile with gcc -o clip clip.c -lX11 to avoid make errors.– the_velour_fog
Jun 3 '17 at 0:11
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f368775%2fhow-do-command-line-clipboard-tools-like-xclip-and-xsel-persist-the-clipboar%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
