Why has xclip -loop 1 stopped working?

Question

If I use e.g.

  echo 'test' | xclip -i -selection primary -loops 1 -quiet

and paste into another terminal window, it works as expected, i.e. 'test' is pasted and then the primary selection goes back to the previous client, 'test' is gone. However, if I paste into an X program, this does not work. If I use -loops 10, I can see that 'test' is pasted to the application on the fourth loop in e.g. gedit and a webkit browser, in firefox it is even the seventh loop. If I use xsel instead, I get the following behaviour:

echo 'test' | xsel -i -p -n -vvvv
xsel: Window id: 0x2e00001 (unmapped)
xsel: Timestamp: 2495171514
xsel: Maximum request size: 4000 bytes
xsel: Accumulated 5 bytes input
xsel: handle_selection_request, property=0x1ca (<unknown atom>), target=0x23d (<unknown atom>)
xsel: Refusing conversion
xsel: handle_selection_request, property=0x1ca (<unknown atom>), target=0x1a9 (TARGETS)
xsel: change_property ()
xsel: data within maximum request size
xsel: Confirming conversion
xsel: handle_selection_request, property=0x1ca (<unknown atom>), target=0x121 (UTF8_STRING)
xsel: change_property ()
xsel: data within maximum request size
xsel: Confirming conversion

The same happens if I use clipboard instead of primary. What happens in the first few loops and where does the data go?

Note: This is of interest since in password managers, you may want to paste the password exactly once...

Another note: I remember that this used to work at some point in the past, probably on an old Ubuntu version. Now I can reproduce this behaviour on Ubuntu 12.04 and also on Debian testing.

score 3 · Accepted Answer · edited Oct 09 '15 at 13:28

See the following Debian bug:

I use xclip -l 1 to paste stuff to Iceweasel. This used to work very well, but broke in Iceweasel 26. This is because Iceweasel 26 probes the PRIMARY clipboard for TARGETS multiple times before it actually requests the UTF8_STRING contents, which causes xclip to exit prematurely. Upstream committed a fix for this behavior:
http://sourceforge.net/p/xclip/code/85/
I would be grateful if you cherry-picked the patch for Debian. Thanks for considering.

To solve apply the following patch and recompile:

-- a/trunk/xclib.c
+++ b/trunk/xclib.c
@@ -411,6 +411,10 @@
    XSendEvent(dpy, evt.xselectionrequest.requestor, 0, 0, &res);
    XFlush(dpy);

+   /* don't treat TARGETS request as contents request */
+   if (evt.xselectionrequest.target == targets)
+       return 0;
+
    /* if len < chunk_size, then the data was sent all at
     * once and the transfer is now complete, return 1
     */

http://anonscm.debian.org/gitweb/?p=collab-maint/xclip.git;a=blob_plain;f=debian/patches/01_dont-treat-TARGETS-as-contents.patch;h=1fe637d7ca9ee6ac1dbf8ea4b68ae0381e7558e2;hb=ba750dfa3a9527aede5ac1d8ebc9b98979433b87

Why has xclip -loop 1 stopped working?

1 Answers1