Passage de commandes à un autre programme

Version imprimable

15/02/2009, 15h16
hpccpp

Passage de commandes à un autre programme

Bonjour.

J'essaye de réaliser une interface graphique pour un programme qui s'utilise au départ en lignes de commande.
Je voudrais utiliser directement l'exécutable de ce programme, je pense que ce serait plus simple que de modifier les sources et tout recompiler avec mon interface graphique.

Mon programme "interface" doit exécuter le programme d'origine, lui envoyer une commande, lire la réponse, envoyer une autre commande, et ainsi de suite...

Le programme d'origine n'est pas sensé "savoir" qu'il communique avec un autre programme, il croit que c'est l'utilisateur qui entre des commandes dans le terminal.

Mais je ne sais pas quelles fonctions C il faut utiliser...
J'ai vu pas mal de choses (popen(), select(), poll(), ...), mais je suis un peu perdu avec toutes ces fonctions.
Faut-il utiliser un "tube", un socket ?
15/02/2009, 15h29
orfix

Renseignes toi sur la fonction system.

Ce que je ferais pour récupérer le résultat c'est le rediriger vers un fichier puis aller lire ce fichier tout simplement.
15/02/2009, 16h45
tonton fred

Salut,

Si la solution de ssmario2 ne te convient pas tu peux (dois?) faire comme ceci:
- creer 2 tubes (un dans le sens interface -> prog, et un pour l'autre sens)
- fork
- dans le fils, connecter une extremite du premier tube a stdin et une extremite du second a stdout
- dans le fils toujours, exec(programme).
- dans le pere, ecrire dans le tube connecte a stdin du fils et lire dans le tube connecte a stdout du fils

Il te faudra fermer les extremites non utilisees dans le pere et le fils, jouer du select ou poll dans le pere pour ne pas bloquer.

Chercher sur google ou ce forum avec les mots clefs pipe, fork, dup2, exec et les pages de man associees devrait te donner des exemples pour commencer.
Un bon debut ici pour un exemple dans un seul sens et sans utilisation de stdin / stdout.

Merci tonton fred, j'ai essayé de programmer ce que tu m'a dit.

Ça donne ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
 
int main (int argc, const char * argv[])
{
	int tube1[2];
	int tube2[2];
	pid_t pid;
 
	// Ouverture du premier tube
	if (0 != pipe(tube1))
	{
		perror("Problème pour ouvrir le premier tube.\n");
		exit(1);
	}
 
	// Ouverture du deuxième tube
	if (0 != pipe(tube2))
	{
		perror("Problème pour ouvrir le deuxième tube.\n");
		exit(1);
	}
 
	// Séparation du programme en deux
	pid = fork();
 
	if (pid == -1)
	{
		perror("Problème pour séparer le programme en deux.\n");
		exit(0);
	}
	else if (pid == 0)
	{
		// FILS
 
		// Fermeture du côté "écriture" du tube 1
		close(tube1[1]);
		// Fermeture du côté "lecture" du tube 2
		close(tube2[0]);
 
		// Connexion du côté "lecture" du tube 1 sur stdin
		dup2(tube1[0], 0);
		// Connexion du côté "écriture" du tube 2 sur stdout
		dup2(tube2[1], 1);
 
		// Exécution du programme en ligne de commande
		execl("/Users/nicolas/Documents/programme", NULL);
	}
	else
	{
		// PÈRE
 
		// Fermeture du côté "lecture" du tube 1
		close(tube1[0]);
		// Fermeture du côté "écriture" du tube 2
		close(tube2[1]);
 
		// Envoi des commandes et lecture des réponses
		char *commande;
		char buffer[100];
 
		commande = "5\n";
		write(tube1[1], commande, strlen(commande));
		read(tube2[0], buffer, sizeof(buffer));
	}
 
    return 0;
}

Evidemment, ça marche pas du premier coup, mais je pense qu'il n'y a plus grand chose à changer pour que ça marche.

Le seul truc que j'ai pas fait, c'est "jouer du select ou poll dans le pere pour ne pas bloquer", tu pourrais expliquer un peu plus ?

Citation:

Envoyé par hpccpp

Le seul truc que j'ai pas fait, c'est "jouer du select ou poll dans le pere pour ne pas bloquer", tu pourrais expliquer un peu plus ?

Une explication tres claire du pourquoi ici.
Dans ton cas tu sembles ecrire une fois puis lire une fois, donc ca ne devrait pas etre necessaire. Cependant, si tes programmes doivent communiquer plusieurs fois dans les deux sens alors tu devras utiliser select ou poll.
Exemple avec select:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 fd_set ecriture, lecture; FD_ZERO(ecriture); FD_ZERO(lecture); FD_SET(tube1[1], &ecriture); FD_SET(tube2[0], &lecture); while (jai-des-trucs-a-faire) { if (select(MAX(tube1[1], tube2[0]) + 1, &lecture, &ecriture, NULL, NULL) > 0) if (FD_ISSET(tube1[1], &ecriture) write(tube1[1], .....); if (FD_ISSET(tube2[0], &lecture) read(tube2[0], ......); }
Une petite remarque: apres dup2 tu peux fermer l'extremite du tube.
Code:

1 2 3 4 dup2(tube1[0], 0); close(tube1[0]); dup2(tube2[1], 1); close(tube2[1]);

16/02/2009, 13h24
souviron34

ça c'est monter une usine à gaz pour faire un truc simple :roll:

Citation:

Envoyé par hpccpp

Bonjour.

J'essaye de réaliser une interface graphique pour un programme qui s'utilise au départ en lignes de commande.
Je voudrais utiliser directement l'exécutable de ce programme, je pense que ce serait plus simple que de modifier les sources et tout recompiler avec mon interface graphique.

Mon programme "interface" doit exécuter le programme d'origine, lui envoyer une commande, lire la réponse, envoyer une autre commande, et ainsi de suite...

Le programme d'origine n'est pas sensé "savoir" qu'il communique avec un autre programme, il croit que c'est l'utilisateur qui entre des commandes dans le terminal.

En dehors de la solution de ssmario2 (qui est déjà nettement plus simple que les tubes), en voici une autre :

Il suffit de simuler un tube (pipe) :

rediriger la sortie du premier programme vers le second, dans lequel on lit stdin...

on peut aussi rediriger la sortie du premier programme vers un fichier et se servir de ce fichier comme stdin.
16/02/2009, 15h13
tonton fred

Citation:

Envoyé par souviron34

En dehors de la solution de ssmario2 (qui est déjà nettement plus simple que les tubes), en voici une autre :

Il suffit de simuler un tube (pipe) :

Juste pour etre sur, qQu'entends-tu par "simuler un tube" ? La redirection?

Citation:

Envoyé par souviron34

rediriger la sortie du premier programme vers le second, dans lequel on lit stdin...

on peut aussi rediriger la sortie du premier programme vers un fichier et se servir de ce fichier comme stdin.

Et un deuxieme fichier pour lire la reponse du programme ?
Je rappelle la question:

Citation:

Envoyé par hpccpp

Mon programme "interface" doit exécuter le programme d'origine, lui envoyer une commande, lire la réponse, envoyer une autre commande, et ainsi de suite...

Et le "ainsi de suite" de la question me fait penser que cela devra tourner dans une boucle, donc il faut gerer les acces concurrents a deux fichiers, le fifo (les fichiers sont plutot des piles) etc. Donc "l'usine a gaz" devient nettement plus interressante a mon avis ;)
Mais si tu as plus simple, ca m'interresse aussi :D
16/02/2009, 15h36
souviron34
reprenons alors simplement :
- le premier programme (langage de commande) a ses entrées et sorties automatiquement redirigeables instantanément (stdin et stdout). (que ce soit à la main, dans un fichier "pipé" en ligne, etc etc.)
- reste le second.
  
  Il suffit :
  - en entrée : re-diriger le stdin, ou lire le fichier de sortie du premier
  - en sortie : rediriger le stdout sur le stdin du premier, ou écrire dans le fichier stdin du premier.
16/02/2009, 15h57
matafan

Je ne vois pas trop en quoi ce que tu proposes est différente de la solution avec deux tubes ?

Merci pour vos réponses.

Mais j'ai un petit problème :
Quand mon programme en ligne de commande démarre, il envoie une ligne pour dire qu'il a démarré.
Et j'arrive même pas à récupérer cette ligne.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 #include <stdio.h> #include <string.h> #include <stdlib.h> #include <unistd.h> int main (int argc, const char * argv[]) { int tube1[2]; int tube2[2]; pid_t pid; // Ouverture du premier tube if (0 != pipe(tube1)) { perror("Problème pour ouvrir le premier tube.\n"); exit(1); } // Ouverture du deuxième tube if (0 != pipe(tube2)) { perror("Problème pour ouvrir le deuxième tube.\n"); exit(1); } // Séparation du programme en deux pid = fork(); if (pid == -1) { perror("Problème pour séparer le programme en deux.\n"); exit(0); } else if (pid == 0) { // FILS // Fermeture du côté "écriture" du tube 1 close(tube1[1]); // Fermeture du côté "lecture" du tube 2 close(tube2[0]); // Connexion du côté "lecture" du tube 1 sur stdin dup2(tube1[0], 0); close(tube1[0]); // Connexion du côté "écriture" du tube 2 sur stdout dup2(tube2[1], 1); close(tube2[1]); // Exécution du programme en ligne de commande execl("/Users/nicolas/Documents/programme", "programme", (char*)0); } else { // PÈRE // Fermeture du côté "lecture" du tube 1 close(tube1[0]); // Fermeture du côté "écriture" du tube 2 close(tube2[1]); // Lecture du premier message char buffer[128]; read(tube2[0], buffer, sizeof(buffer)); printf("Le programme a répondu : '%s'.\n", buffer); } return 0; }
Quand j'exécute ça, rien ne s'affiche, et le programme a l'air d'attendre indéfiniment que quelque chose arrive dans read();

Pour lire juste cette ligne, je n'ai pas encore besoin de select().
Il faudrait déjà que j'arrive à faire ça avant de faire des lectures/écritures multiples.

Le programme en ligne de commande démarre bien, parce que si j'"oublie" de rediriger stdin et stdout, j'ai bien le message qui s'affiche.

Dans cet exemple, je me contente d'écrire "Le programme a répondu : ...", c'est juste pour tester. Une fois que ça marchera, j'utiliserai la réponse pour autre chose.

Est-ce que le fait que j'utilise Mac OS X (et pas Linux) peut justifier le fait que ça marche pas ? Je pense pas, mais bon...

16/02/2009, 16h26
souviron34

Citation:

Envoyé par matafan

Je ne vois pas trop en quoi ce que tu proposes est différente de la solution avec deux tubes ?

oh rien, juste la complexité du code et des notions... :aie:

(suffit de voir le post ci-dessus)
16/02/2009, 16h35
tonton fred

read() est bloquant, donc si ton programme "programme" n'ecrit rien alors le pere attend. Tu es sur que "programme" ecrit?

souviron34: maintenant c'est plus clair :D
ben en redirigeant l'entree et la sortie dans le shell il va quand meme falloir gerer le fait que ce sont des communications asynchrones non?

Citation:

Envoyé par tonton fred

souviron34: maintenant c'est plus clair :D
ben en redirigeant l'entree et la sortie dans le shell il va quand meme falloir gerer le fait que ce sont des communications asynchrones non?

Et ??

Dans ta biblothèque graphique, tu dois bien avoir une fonction UpdateDisplay() ou quelque chose comme ça qui traite les évènements graphiques (souris ou autres), non ??

Alors ça revient à quelque chose comme (dans ton main graphique ou dans la callback où tu traites le lancement de ce programme) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 while ( 1 ) { /* gère les événements graphiques */ UpdateDisplay(); /* test si le fichier à changé (ftell/fseek/fpos ou stat) */ /* si oui */ /* lit le fichier de sortie de l'autre programme */ /* Va écrire la suite dans le fichier d'input pour l'autre programme */ /* fin si */ }

16/02/2009, 17h08
tonton fred

Je sens que je t'agace alors juste une derniere avant de manger :aie:
Simplement, en quoi c'est plus simple?
Ok il n'y a pas les pipe / dup / select, mais la difference est d'au plus une dizaine de lignes parmi les centaines que doit contenir une interface graphique. Par contre on ne depends pas d'un processus externe (le shell) et on s'affranchit des contraintes liees aux fichiers: permissions, gestion des crashs... Rien de complique bien sur mais a l'arrivee je ne pense pas (et ca n'engage que moi) que ce soit "plus simple".
Et puis je trouve ca moins propre (ca aussi ca n'engage que moi).
16/02/2009, 17h48
souviron34

tu ne m'agaces pas du tout, mais encore une fois je ne vois pas l'intérêt d'ajouter encore des notions et des outils pour quelque chose qu'on peut faire de base...

Mais tu ne dépends pas d'un processus externe : la norme C est indépendante des shells, et pourtant elle permet de redéfinir stdin et stdout..

Et ouvrir un fichier ne dépend pas des shells..

C'est plus simple parce que pour répondre à une fonctionalité, on y répond. Sans en ajouter 5 ou 6 de plus...

Alors justement sur un programme d'interface, je te demande : pour un petit prog, pas de problèmes si tu rajoutes 10 ou 50 lignes.. Mais si tu fais ça à chaque fonctionalité, en trouvant une solution compliquée à un problème simple, tu auras une usine à gaz à la fin...

Et c'est plus "propre", car il est relativement rare d'avoir un programme qui ne s'occupe pas de fichiers. Donc tu auras de toutes façons déjà les routines pour manipuler des fichiers. Mais là en plus tu rajoutes une notion, un fichier d'entête, et des fonctions...

Enfin, pour l'avoir vécu, c'est autrement plus emmerdant à débugger des codes avec des pipes qu'avec des entrées/sorties directes...

MAis bon, c'est mon avis...

Il peut y en avoir d'autres....

PS: dernier point : si tu as géré via des fichiers, tu peux remplacer ton interface par un script....
16/02/2009, 18h19
matafan

Le problème c'est qu'apparement les deux programmes ont besoin de communiquer entre eux, pas seulement de s'envoyer un paquet de données. Donc ça suppose une certaine logique dans la programme "pilote" pour envoyer les bonnes données au bon moment. Et tu ne peux pas faire ça avec les fonctionalités du shell (enfin, sans installer expect...). Donc il ne devra probablement gérer lui même ses pipes en C.
16/02/2009, 18h22
souviron34

Citation:

Envoyé par matafan

Le problème c'est qu'apparement les deux programmes ont besoin de communiquer entre eux, pas seulement de s'envoyer un paquet de données. Donc ça suppose une certaine logique dans la programme "pilote" pour envoyer les bonnes données au bon moment. Et tu ne peux pas faire ça avec les fonctionalités du shell (enfin, sans installer expect...). Donc il ne devra probablement gérer lui même ses pipes en C.

je répète que je ne vois pas de problèmes avec le fait de le faire via stdin/stdour par fichier..

..
16/02/2009, 18h45
matafan

Je n'ai pas du comprendre ce que tu proposes.