Discussion :

[Truemanshow]

Bonjour,

ma question peut paraître farfelue puisqu'en fait qui s'en soucie. L'application graphique va communiquer via son interface graphique et le deamon n'est pas sensé communiquer.
Et pourtant cela pourrait être pratique, je pense. Je vais essayer de donner des exemples.

Mais avant tout, je suis parti du principe que tout programme, quelque soit son type, est pourvu d'entrée/sortie standard. Dites moi tout de suite si je me trompe, ce sera toujours ça d'appris. Ou alors, cela n'existe qu'à la condition d'inclure la bibliothèque <stdio.h>? De toute façon, elle sera nécessaire pour ce que je veux faire.
Dit autrement, si d'une application graphique ou d'un daemon, je fais un printf, dans quel trou noir cela va t'il? Il y a t'il moyen de le récupérer?

Alors, pourquoi faire?
Imaginons que j'écrive un programme qui va faire son job de façon autonome et donc, je veux en faire un daemon. A un moment, je veux changer ses paramètres de fonctionnement bien entendu sans l'interrompre. Je peux également vouloir l'interroger sur son statut. Un routeur est un bon exemple.
Donc, après avoir écrit le programme, je lui adjoins un thread (ben oui, je ne vois pas comment faire autrement) dont le rôle est d'attendre des commandes sur son entrée standard et y répondre sur sa sortie. Ces dernières n'étant connectées en temps normal à rien, ce thread est le plus souvent en standby. Sauf quand à partir d'un terminal, je m'y connecte d'une façon que justement je cherche ici.

En résumé, je lance un terminal et je le connecte au flux entrée/sortie d'un process qui attendait juste à qui parler. Est-ce possible?
Cela reviens à vouloir entrer en communication avec son démon. Je suis sûr que si j'en parle à ma femme, elle va me sortir un bouquin ésotérique.

Et pour une appli graphique, j'aurais bien envie de pouvoir faire la même chose même si c'est loufoque. A ma connaissance, le widget "terminal" n'existe pas ou alors il faut me le dire.

Merci d'avance pour vos réponses.

[LittleWhite]

Bonjour,

Toutes applications reçoit trois canaux :

• l'entrée standard (STDIN) ;
• la sortie standard (STDOUT) ;
• la sortie d'erreur (STDERR).

Ces canaux peuvent être connectés, comme ils peuvent ne pas l'être. Si on lance le programme à partir d'un terminal, les canaux sont connectés par le terminal (il lit ce qui sort de STDOUT, pour l'afficher, il écrit sur STDIN pour l'envoyer à l'application). Note : il y a beaucoup d'autres façons de communiquer avec une application.
Un programme graphique n'est généralement pas lancer à partir du terminal. Toutefois, lorsqu'elle l'est, il lui arrive d'écrire sur STDOUT/STDERR et cela s'affiche sur le terminal, car il lit ce qui sort. Idem pour STDIN. Simplement, un programme graphique n'a pas comme objectif d'utiliser le terminal rudimentaire pour communiquer avec l'utilisateur.
Un daemon ... en réalité, ce n'est qu'un programme, sans interface graphique, mais qui n'est pas lancé par le terminal. C'est lancé par un processus spécifique, qui redirigera la sortie (STDOUT/STDERR) dans des fichiers (ou pas).

[Truemanshow]

Merci,

c'est un peu comme ça que je le devinais. J'ai eu l'espoir de trouver un moyen basique de me connecter au flux d'un programme qui n'attend pas forcément de l'être. Donc, je dois trouver le moyen approprié pour communiquer avec un programme qui n'est pas lancé dans un terminal. Je me rappelle vaguement avoir paramétré une base de donnée en ligne de commande alors qu'elle tournait en live bien entendu. C'était il y a longtemps et je suis presque sûr d'avoir du utiliser un petit utilitaire.

Si je comprend bien, je dois écrire un programme client pour me connecter à un daemon, lui envoyer des commandes et l'interroger?
J'ai un peu prospecté du coté des communications interprocesses. J'ai trouvé des pipes (mais je crois que c'est pour les forks), des fifos, des shared memory et des sockets.
Qu'est ce qu'on utilise dans ce cas?

[LittleWhite]

Pour un daemon, cela sera des sockets ... enfin, si le démon à prévu se type de communication ...
Vous pouvez faire des interactions basiques avec les signaux, style SIGUSR.

[BufferBob]

salut,

accessoirement tu peux envisager -c'est pas très orthodoxe mais ça doit fonctionner- d'aller récupérer simplement dans /proc/<PID>/fd/, tout dépendra du besoin, s'il est question de faire propre et d'avoir la main sur le code du daemon en question, mieux vaut utiliser les sockets comme préconise LittleWhite, à noter également qu'il existe xinetd qui est capable de prendre ton programme qui écrit sur stdout (grossièrement) et en faire un daemon

[Truemanshow]

Merci pour vos réponses, maintenant je sais dans quelle direction aller.
Le SIGUSR, je ne connaissais pas, bon à savoir. /proc/<pid>/fd/ et xinetd, ça fait un peu peur. En tout cas, cela montre que vous êtes tous les deux plutôt balèzes.

Je retiens donc que les sockets sont LA façon de communiquer avec un démon. Je suppose que je dois écrire un petit client tournant dans un terminal et qui va faire une sorte de passerelle? J'ai fait quelques recherches et je crois que cela pourrais ressembler à ça:

char uneCommande[32];
char laReponse[1024];

while(1) {

fgets(uneCommande,sizeof(uneCommande),stdin);
if (strcmp(uneCommande,"quit")==0) break;
send(monSocket,uneCommande,sizeof(uneCommande),0);
recv(monSocket,laReponse,sizeof(laReponse),0);
printf("%s",laReponse);
}

Voilà, il y a sûrement des fautes mais c'est plus ou moins l'idée. L'utilisateur entre une commande, celle çi est envoyée au deamon. Celui-ci est doté d'un thread qui va servir de handler. Il va interpréter la chaîne de caractère, la traiter et renvoyer un message au client qui va l'afficher. Qu'en pensez vous?