为什么xclip -loop 1停止工作？

Question

如果我使用例如

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

并粘贴到另一个终端窗口，它按预期运行，即，“测试”被粘贴，然后将初级选择追溯到以前的客户端，“测试”不见了。但是，如果我粘贴到X程序中，这不起作用。如果我使用-loops 10，我可以看到'test'被粘贴到例如第四个循环中的应用程序上。 gedit和webkit浏览器，在Firefox中它甚至是第七个循环。如果我使用xsel相反，我得到了以下行为：如果我使用clipboard代替primary

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 

同样的情况。在前几个循环中会发生什么以及数据在哪里发生？

注：这是兴趣，因为在密码管理器，你可能要粘贴密码恰好一次......

另注：我记得这个曾经在某一点在过去的工作，可能在旧的Ubuntu版本上。现在我可以在Ubuntu 12.04以及Debian测试中重现这种行为。

Answer 1

见following Debian bug：

我用xclip -l 1来的东西粘贴到Iceweasel。这用于很好地工作 ，但打破了Iceweasel 26.这是因为在实际请求 UTF8_STRING内容之前，Iceweasel 26多次探测目标的主剪贴板，这导致xclip过早退出。 上游承诺对此行为进行修复：
http://sourceforge.net/p/xclip/code/85/
如果您选择了Debian的修补程序，我将不胜感激。感谢 供考虑。

为了解决应用the following patch并重新编译：

-- 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