跟踪它时,xclip不会终止

我提出以下意见:

$ xclip text.txt 

执行立即终止,它将text.txt的内容复制到默认selectXA_PRIMARY ,这意味着您可以通过鼠标中键或xclip -o粘贴它。

当我想看看xclip在做什么时,它不会终止:

 $ xclip -verbose text.txt Connected to X server. Using UTF8_STRING. Reading text.txt... Waiting for selection requests, Control-C to quit Waiting for selection request number 1 

它不会终止,直到我在我的X11系统中select了一些东西,例如我在这里粘贴的输出。 我会理解这一点,如果行为是有限的verbose 。 毕竟你想坐下来看看会发生什么。

我可以用strace重现相同的行为,但只有在提供了fork选项的情况下

 $ strace -f xclip text.txt 

或者从Ruby中用一个应该返回输出的系统执行命令(实际上什么都不是)从shell中退出。

 $ ruby -e "`xclip text.txt`" 

strace给出的提示是轮询文件描述符以等待事件。 如果我select了一些东西,这个事件是满足 这种行为是可以解释的吗? 我有证据certificate,这在任何系统上都不可重现。 这可能与票#9相关的标准input设置剪贴板时不closures标准输出 ?

我在Ubuntu 13.04上运行xclip版本0.12。

Solutions Collecting From Web of "跟踪它时,xclip不会终止"

XClip在没有任何动作的情况下推出一个小孩。 与-verbose的唯一区别是没有分叉子,并且相同的原始进程处理ConvertSelection事件。

通常在X Window工具箱中复制/粘贴通过X选择来实现:

选择是由原子命名并由特定客户所拥有的全局服务器资源。 选择的数量不受协议的限制; 因为可能存在许多与原子相同的选择。 选择旨在为建立客户之间的沟通机制提供基础。 官方定义见X议定书的格式:

“…具有动态类型的间接属性;也就是说,不是将属性存储在服务器中,而是由某个客户端(”所有者“)维护。选择具有全局性,被认为是属于用户(虽然由客户维护),而不是私有的特定的窗口子层次结构或特定的客户端。

从应用程序的角度来看,选择提供了一种在X客户端之间传输信息的机制。 由于X是一种网络协议,因此不能假设存在用于各种客户端之间的数据传输的独立信道的存在。 选择仅用于与应用程序的用户界面方面直接相关的数据传输,尽管没有任何此策略的实施。

选择的内容存储在应用程序本身,并通过ConvertSelection事件请求(这里的“convert”,因为有一种方法可以让客户请求特定的mimetype(或“查看”,或格式)选择的数据。拥有所选缓冲区的应用程序。

由于这种架构,没有办法“将文本复制到系统缓冲区并退出” – 因为您是系统缓冲区。 XClip通过分叉和守护进程模拟“复制和退出”。