Il est possible de piloter l'émulateur de terminal KDE (Konsole) à distance, en utilisant DCOP. Ca peut etre très très pratique.
Par exemple, je travaille à l'heure actuelle sur un jeu en reseau. Pour le tester, j'ai besoin de lancer souvent un serveur et deux clients qui se connectent. Chaque programme écrit des informations cruciales sur sa sortie standard, donc les lancer tous en arriere plan avec un simple & n'est pas une solution très pratique: toutes les sorties standards sont mélangées. En plus, ca m'oblige a quitter un par un mes clients et mon serveur. Au lieu de cela, j'ai utilisé un script pour lancer le serveur et chacun des clients dans une des sessions d'une fenêtre konsole. l'appel dcop newSession ouvre une nouvelle session sous konsole, et l'appel sendSession envoie du texte, comme s'il etait tape en ligne de commande. Voici mon script:
# launch konsole with remote dcop control enabled
konsole --script &
# process-id is used to generate the dcop name of konsole
kid=konsole-$!
echo Konsole is $kid
session="session-1"
# you need to add a small delay
sleep 0.5
echo Starting Camino server
# execute the server on the first session
dcop $kid $session sendSession "./camino --server --$players"
sleep 0.5
echo Starring Camino client phil
# create a new session
session=`dcop $kid konsole newSession`
# execute the first client in the second session
dcop $kid $session sendSession './camino --player phil'
sleep 0.5
echo Starring Camino client bob
# create a new session
session=`dcop $kid konsole newSession`
# execute the first client in the second session
dcop $kid $session sendSession './camino --player bob'
Le résultat, c'est un nouvelle konsole avec trois sessions, faisant tourner mon serveur et mes clients. Je peux passer de l'une à l'autre en utilisant shift+curseur droit ou gauche. Il me suffit de fermer la konsole pour tuer mes trois processus d'un coup.
Notons que pour des raisons de sécurité, la commande dcop sendSession n'est disponible que si on lance konsole avec l'option --script.
Là, j'ai utilisé dcop en shell mais il existes des bindings python, perl, c, c++, java...
Toutes les applications KDE peuvent être pilotées ainsi à distance. Cà permet de se faire des petits scripts intelligents.
# ?
Posté par jmfayard . Évalué à 1.
[^] # Re: ?
Posté par jmfayard . Évalué à 1.
Apparemment, ça marche à partir de kde 3.1
# Re: Scripter le terminal sous KDE
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: Scripter le terminal sous KDE
Posté par Philippe F (site web personnel) . Évalué à 1.
[^] # Re: Scripter le terminal sous KDE
Posté par Jak . Évalué à 1.
mkfifo serveur.fifo
mkfifo client1.fifo
mkfifo client2.fifo
./ camino --server --$players > serveur.fifo &
./camino --player phil > client1.fifo &
./camino --player bob > client2.fifo &
Ensuite, il suffit de faire un cat sur chaque fifo pour voir les différentes sorties.
Unix, ça roulaizze à fond.
# Re: Scripter le terminal sous KDE
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 1.
OK OK, there is more than one way to do it, mais puisqu'il a été fait référence notamment à la sécurité...
[^] # Re: Scripter le terminal sous KDE
Posté par Philippe F (site web personnel) . Évalué à 1.
Sinon, il parait qu'on peut faire la meme chose avec gnome-terminal, a coup de ligne de commande. C'est un truc du genre (j'ai pas la doc sous la main, donc a vous d'adapter):
gnome-terminal --command='./camino --server --$players' --tab --command='./camino --player phil' --tab --command='./camino --player bob'
# Re: Scripter le terminal sous KDE
Posté par ludo P . Évalué à 1.
xterm -e Serveur
xterm -e clien
...
et un control C pour tuer les 3 xterms...
[^] # Re: Scripter le terminal sous KDE
Posté par LaBienPensanceMaTuer . Évalué à 1.
Et après tu peut même récupérer ton screen au boulot !
[^] # Re: Scripter le terminal sous KDE
Posté par fmr69 . Évalué à 1.
il est possible de lancer en une commande plusieurs shells dans un seul screen ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.