xclip ne se termine pas lors du traçage

J’ai fait les observations suivantes:

$ xclip text.txt 

L’exécution se termine instantanément, il copie le contenu de text.txt dans la sélection par défaut XA_PRIMARY ce qui signifie que vous pouvez le coller via le bouton central de la souris ou xclip -o .

Quand je veux voir ce que fait xclip, il ne se termine plus:

 $ 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 

Il ne se termine pas avant que je sélectionne quelque chose dans mon système X11, par exemple ce que j’ai collé ici. Je comprendrais cela si le comportement se limite à la verbose . Après tout, vous voulez vous asseoir et voir ce qui se passe.

Je peux reproduire le même comportement avec strace , mais seulement si l’option fourchette est fournie

 $ strace -f xclip text.txt 

ou en éliminant Ruby avec une commande d’exécution du système qui devrait renvoyer la sortie, ce qui n’est en fait rien.

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

Les indices donnés par strace , c’est qu’il interroge un descripteur de fichier pour attendre un événement. Cet événement est satisfait si je sélectionne quelque chose. Ce comportement est-il explicable? J’ai eu des preuves que cela n’est reproductible sur aucun système. Cela pourrait-il être lié au ticket # 9 Ne ferme pas la sortie standard lors de la définition du presse-papiers depuis stdin ?

Je cours xclip version 0.12 sur Ubuntu 13.04.

XClip transforme un enfant lorsqu’il est lancé sans -verbose . La seule différence avec -verbose est qu’il n’y a pas d’enfant forké et que le même processus original gère les événements ConvertSelection .

Habituellement, dans la fenêtre X, les outils de copie / collage sont implémentés via les sélections X :

Les sélections sont des ressources de serveur globales nommées par un atome et appartenant à un client particulier. Le nombre de sélections n’est pas limité par le protocole; autant de sélections que d’atomes peuvent exister. Les sélections sont conçues pour servir de base à la création de mécanismes de communication entre les clients. La définition du fi nial se trouve dans le glosary du protocole X:

“… une propriété indirecte avec un type dynamic, c’est-à-dire que, plutôt que d’avoir la propriété stockée sur le serveur, elle est gérée par un client (le” propriétaire “). Une sélection est de nature globale et est considérée comme appartenant à l’utilisateur (bien que maintenu par les clients), plutôt que d’être privé à une sous-hiérarchie de fenêtre particulière ou à un ensemble particulier de clients. ”

Du sharepoint vue des applications, les sélections fournissent un mécanisme de transmission d’informations entre les clients X. Comme X est un protocole de mise en réseau, l’existence d’un canal séparé pour la transmission de données entre les différents clients ne peut être présumée. Les sélections sont uniquement destinées au transfert de données, qui relie directement les aspects de l’interface utilisateur de l’application, bien qu’il n’y ait aucune application de cette politique.

Le contenu de la sélection est stocké dans l’application elle-même et demandé avec l’événement ConvertSelection (“convertir” ici car il existe un moyen pour le client de demander un type MIME particulier (ou “vue” ou format) des données sélectionnées. application qui possède le tampon sélectionné.

En raison de cette architecture, il est impossible de “copier du texte dans le tampon système et de quitter” – car vous êtes un tampon système. XClip simule “copier et sortir” en forking et en daemonizing.