我提出以下意见：
$ xclip text.txt执行立即终止，它将text.txt的内容复制到默认选择XA_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系统中选择一些东西，例如我粘贴在这里的这个输出。如果行为仅限于verbose，我会理解这一点。毕竟你想坐下来看看会发生什么。
我可以用strace重现相同的行为，但前提是提供了fork选项
$ strace -f xclip text.txt或者使用系统执行命令从Ruby中输出时，应该返回输出，实际上什么也没有。
$ ruby -e "`xclip text.txt`"strace给出的提示是，它正在轮询文件描述符以等待事件。如果我选择一些东西，这个事件就满足了。这种行为可以解释吗？我有证据表明，这是不可复制的任何系统。这会不会和#9 Not closing stdout when setting clipboard from stdin的罚单有关？
我在Ubuntu 13.04上运行xclip版本0.12。
2条答案
按热度按时间o3imoua41#
XClip在没有
-verbose的情况下启动时派生一个子对象。-verbose的唯一区别是没有子进程，并且相同的原始进程处理ConvertSelection事件。通常在X Window工具包中，复制/粘贴是通过X Selections实现的：
选择是由原子命名并由特定客户端拥有的全局服务器资源。选择次数不受协议限制;可以存在与原子一样多的选择。选择旨在为客户端之间的通信机制提供基础。官方定义见X议定书的词汇表：
“.具有动态类型的间接属性;也就是说，属性不是存储在服务器中，而是由某个客户端（“所有者”）维护。选择本质上是全局的，被认为属于用户（尽管由客户端维护），而不是特定窗口子层次结构或特定客户端集的私有选择。
从应用程序的Angular 来看，选择提供了一种在X客户端之间传输信息的机制。由于X是一种网络协议，因此不能假设存在用于各种客户端之间的数据传输的单独通道。选择仅用于与应用程序的用户界面方面直接相关的数据传输，尽管没有任何强制执行此策略。
选择的内容存储在应用程序本身中，并通过ConvertSelection事件（此处为“convert”，因为客户端有一种方法可以请求所选数据的特定mimetype（或“视图”或格式）。同样，转换发生在拥有选定缓冲区的应用程序中。
由于这种体系结构，没有办法“将文本复制到系统缓冲区并退出”-因为您是一个系统缓冲区。XClip通过分叉和后台进程化来模拟“复制和退出”。
olhwl3o22#
正如公认的答案所解释的那样，这并没有解决问题...被“复制”到剪贴板的数据 * 永远不会 * 复制到剪贴板。相反，剪贴板记录了对进程的引用，该进程预期会产生 * 假装 * 被复制到剪贴板的信息。通过这种方式，剪贴板被设计为处理可能以许多不同方式呈现的大量复杂信息。人们可能会认为简单文本是例外，但没有例外。
因此，将信息“复制”到剪贴板的程序需要继续运行，直到剪贴板的内容被另一个可执行文件替换。如果将信息“复制”到剪贴板的进程结束，则剪贴板的内容将丢失。
xclip立即读取数据，然后将其自身去匿名化到后台，等待在请求时为其提供服务，xclip在计算粘贴请求时称之为“等待选择请求”。
上述工程beauitfully而
将'hi-there'赋值给x，但永远不会返回，因为bash等待xclip向stdout写入一些东西，而这永远不会发生。
xclip进程将属于bash组，但是$(bash...)没有重新分配/proc/$$/fd/1，所以我不知道如何轻松地测试它。但是...返回而不等待xclip结束，因为bash知道xclip的任何可能的输出都不会为它产生输出，因为xclip的标准输出已经被重新分配到其他地方。
* 问题解决！*