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 jice (site web personnel) . Évalué à 3.
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 zebra3 . Évalué à 0.
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 JGO . Évalué à 3.
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 jice (site web personnel) . Évalué à 1.
KDE >= 4 => dbus
[^] # Re: KDE
Posté par jice (site web personnel) . Évalué à 2.
à partir de KDE 4, on utilise dbus.
[^] # Re: KDE
Posté par JGO . Évalué à 2.
[^] # Re: KDE
Posté par jice (site web personnel) . Évalué à 1.
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 ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
/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 ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Intéressant mais …
Posté par JGO . Évalué à 1.
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 blobmaster . Évalué à 0.
É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 JGO . Évalué à 0.
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 Gof (site web personnel) . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.