Journal buffer souris de X au clavier

Posté par .
Tags : aucun
16
4
jan.
2011
xsel[1] et xclip[2] sont deux petits utilitaire en lgne de commande pour manipuler le « buffer » de la souris (en fait, les 3 buffers maintenus par X), que j'ai découverts aujourd'hui et souhaitais partager comme astuce.

Mon utilisation :
Je suis en console loin dans un arbre un peu complexe, puis je veux ouvrir un document dans une application graphique. Je ne veux pas lancer cette application depuis la console, par exemple parce qu'elle est déjà ouverte ou qu'elle a l'habitude d'afficher beaucoup de messages dans stdout et stderr. Je veux donc utiliser l'interface graphique mais il faudrait naviguer dans une arborescence pour ouvrir le fichier. Je préfère afficher le répertoire, sélectionner à la souris, mais je ne suis pas très adroit.

Solution :
/chemin/super/compliqué> $ pwd | xsel (même chose avec xclip)

Le répertoire est maintenant dans le buffer souris, je peux le coller dans la boite de dialogue d'ouverture de fichiers. xclip et xset fonctionnent tous deux mais diffèrent sur leurs possibilités en en ligne de commande. Par exemple :
* xsel -a pour append, -x pour interchanger les buffers primaires et secondaires (et en avoir donc deux, gérables au clavier)
* xclip -l 10 attend que 10 sélections aient été faites successivement avant de quitter.

Pour aller plus loin il y a xcutsel, du paquet xclipboard[2]. xclipboard est un gestionnaire de presse-papiers d'aspect assez frustre qui a été rendu obsolète par les outils intégrés des environnements de bureau (p.ex. Klipper ou gnome-settings-daemon/plugins/clipboard). Pour ceux qui ne lancent pas ces environnements de bureau, xcutsel a une utilité. xcutsel est un petit outil X qui implémente une mémoire du buffer. Si un texte a été sélectionné et qu'on veut le réutiliser plusieurs fois, xcutsel permet de faire « copy PRIMARY to 0 ». La sélection est maintenant dans le buffer 0. la souris peut être utilisée sans crainte de détruire la sélection. Il suffit de faire « copy 0 to PRIMARY » pour récupérer le texte.

N.B. ces programmes refuseront de fonctionner si un autre gestionnaire de presse-papiers est en cours d'exécution. Pour Gnome, la procédure est donnée à [3]. Pour KDE, je n'ai pas tenté, peut-être tuer Klipper s'il est lancé.

Enfin, le lecteur de linuxfr d-jo a écrit un daemon basé sur xclip, qu'il a présenté en journal sur la version alpha de linuxfr il y a quelques mois[4]. Un commentaire de ce journal par gabriel suggère aussi le projet parcellite[5].

[1] http://www.vergenet.net/~conrad/software/xsel/
[2] http://sourceforge.net/projects/xclip/
[3] http://lildude.co.uk/howto-use-xclipboard-with-gnome
[4] https://alpha.linuxfr.org/users/djojo/journaux/klipper-sans-(...)
[5] http://parcellite.sourceforge.net/
  • # KDE

    Posté par (page perso) . Évalué à 3.

    Merci pour l'astuce, très intéressant...

    Pour KDE, il faut envoyer une commande dcop^Wdbus à Klipper (je l'ai pas sous la main, je la posterai depuis la maison ; je m'étais inspiré de ça : http://milianw.de/code-snippets/access-klipper-clipboard-on-(...) ).
    Ca fonctionne mais rien à voir avec xclip dans la simplicité (j'ai adapté le script présent dans le lien, qui en fait peut-être utilisé grossièrement comme xsel).
    • [^] # Re: KDE

      Posté par . Évalué à 0.

      Pour GNOME, c'est juste « $ pwd | parcellite ».

      Encore une preuve que GNOME est aussi simple que la CLI et plus que KDE :-)

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: KDE

        Posté par . Évalué à 3.

        1) Parcellite n'est pas une application gnome, c'est une application gtk+ séparée [troll] qui pallie aux limitations du presse papiers de gnome [/troll]. Je pourrais aussi essayer parcellite mais je n'aime pas les applications qui restent en icones de tray, je préfère les petits outils UNIX qui font un seul truc et bien.
        2) Pour kde après recherche c'est
        dcop klipper klipper setClipboardContents "$(cat)"
        Certes c'est plus compliqué mais tu peux le mettre dans un script de 1 ligne [1].

        En fait mon critère c'est que je ne veux pas lancer de gestionnaire de bureau. J'utilise slim/fluxbox, nedit, rxvt. Je ne veux pas lancer kde ou gnome par dessus.

        [1] http://www.linuxquestions.org/questions/programming-9/python(...)
        • [^] # Re: KDE

          Posté par (page perso) . Évalué à 1.

          KDE < 4 => dcop
          KDE >= 4 => dbus
        • [^] # Re: KDE

          Posté par (page perso) . Évalué à 2.

          dcop est pour KDE jusqu'à la version 3.5
          à partir de KDE 4, on utilise dbus.
          • [^] # Re: KDE

            Posté par . Évalué à 2.

            arf merci... J'ai utilisé kde jusqu'à la 3.5.9, j'y suis pas encore revenu. KDE 4 est sans doute stable maintenant mais plasma est très gourmand pour ma machine (alors que fluxbox est rapide comme pas permis même sur du vieux matos).
        • [^] # Re: KDE

          Posté par (page perso) . Évalué à 1.

          pour KDE >= 4
          qdbus org.kde.klipper /klipper getClipboardContents
          et
          qdbus org.kde.klipper /klipper setClipboardContents "$(cat)"
          (me paraît plus simple que la méthode avec dbus-send utilisée dans le script dont j'ai donné l'adresse ci-dessus)
  • # Intéressant mais …

    Posté par (page perso) . Évalué à 5.

    Est-ce que ce n'était pas plus simple de lancer l'application comme ça :
    /chemin/super/compliqué> appli monfichier &> /dev/null &
    De toute façons même une application qui ne vérifie pas si une autre instance d'elle même est déjà lancée ne consomme pas beaucoup plus de ressources en étant instanciée N fois plutôt qu'une seule. Il me semble que c'est là l'un des grands apports des librairies dynamiques. Non ?
    • [^] # Re: Intéressant mais …

      Posté par . Évalué à 1.

      Dans le cas d'inkscape, si tu lances deux instances tu perds la possibilité de copier-coller entre les deux dessins.

      Ensuite, sur la ligne de commande tu n'as accès qu'à la commande ouvrir, mais les applications ont parfois plusieurs dialogues (ouvrir, enregistrer, enregistrer une copie, importer...) qui peuvent toutes avoir un chemin différent. C'est le cas général dans Inkscape et c'est aussi le cas dans certains dialogues de OOo.
      • [^] # Re: Intéressant mais …

        Posté par . Évalué à 0.

        En ce qui concerne inkscape.
        Étant donné que J'arrive à copier/coller depuis (et vers) :
        - firefox
        - gimp

        Comment ce ferait-il que tu ne puisses copier coller depuis inkscape (vers inkscape).
        Ça paraît étrange c't'affaire.

        Je test, j'ouvre deux instance d'inkscape ("inkscape &" depuis deux konsole différentes) et ... chez moi ça marche, je copie colle.

        Question :
        Qu'appel-tu deux instances ?
        J'utilise KDE qui est surpuissant, j'imagine que tu es sous gnome... Je vois pas d'autres explications.
        • [^] # Re: Intéressant mais …

          Posté par . Évalué à 0.

          > Qu'appel-tu deux instances ?
          Quand je lance inkscape depuis un gestionnaire de fichiers en cliquant successivement sur deux svg, le comportement n'est pas le même que si j'ouvre deux fichiers depuis le menu de inkscape.

          > j'imagine que tu es sous gnome...
          je n'utilise pas de gestionnaire de bureau, mon gestionnaire de fenêtrage est fluxbox.
  • # Re: buffer souris de X au clavier

    Posté par (page perso) . Évalué à 1.

    J'utilise beaucoup xclip. Je n'ai jamais remarqué de problème avec klipper de KDE.

    J'utilise aussi souvent
    xclip -o > foo.txt
    pour enregistrer le contenu du presse papier dans un fichier.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.