[Linux]comment intercepter le stdin ?

Version imprimable

Bonjour

J' ai besoin d'intercepter le stdin dans mon programme d'un processus fils
exemple:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 pid_t pid = fork(); if (pid == 0) { ..... .... execvp("tr","a-z","A-Z"); //commande unix pour convertir une chaine en Maj } else if (pid == 1) { wait(&staus) ..... .... comment recupere l'entré passé a la commande tr dans le terminal ??? }
je veux récupérer le text taper a la commande "tr" pour l'utliser plus tard dans le processus Pere sans blocké le stdin?? :roll:

Merci

Ton utilisation de fork() est erronée, on l'utilise comme ça:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 pid_t pid = fork(); if(pid == -1) { /* error */ } else if(pid == 0) { /* son */ } else { /* father : pid = son's pid */ }
cordialement

22/11/2010, 13h12
matafan

Si tu veux capturer ce que l'utilisateur envoie à la commande tr, la seule solution est de lire toi-même (dans le process père) stdin, puis de passer les données lues au process fils (tr) via un pipe connecté au stdin de de tr. Tu auras besoin de pipe() (avant le fork) et de dup2() (dans le process fils, entre le fork et le exec).
22/11/2010, 15h04
Edw@rd
Citation:

Envoyé par matafan

Si tu veux capturer ce que l'utilisateur envoie à la commande tr, la seule solution est de lire toi-même (dans le process père) stdin, puis de passer les données lues au process fils (tr) via un pipe connecté au stdin de de tr. Tu auras besoin de pipe() (avant le fork) et de dup2() (dans le process fils, entre le fork et le exec).

Je comprend ce que vous voulez dire...et tous mes fork() et pipe() son bien configurer....
mais, admettons que je veut passer plusieurs texte a la commande "tr" jusqu'a la fermeture de stdin (^D)
Code:

1 2 3 4 5 6 7 8 9 10 $ tr a-z A-Z hello <- HELLO bonjour <- BONJOUR pomme <- POMME ^D $
ici le process pere recupere : hello,bonjour , pomme.
j'ai vue dans des forum qu'ils parlent du poll(). mais je comprend pas comment l'utiliser.....
22/11/2010, 15h21
nicolas.sitbon

Tout ça n'est pas très clair...
Commence par nous expliquer ce que tu souhaites réaliser, sans parler de programmation, ensuite on verra s'il y a vraiment de besoin de spawner un nouveau processus et de faire aussi compliqué.
22/11/2010, 15h30
Edw@rd

Citation:

Envoyé par nicolas.sitbon

Tout ça n'est pas très clair...
Commence par nous expliquer ce que tu souhaites réaliser, sans parler de programmation, ensuite on verra s'il y a vraiment de besoin de spawner un nouveau processus et de faire aussi compliqué.

j'ai besoin permettre a l'utilisateur de passer la commande "tr" a mon programme:

Code:

$monprogramme tr a-z A-Z

et par la suite mon programme doit intercepter tous les mots taper dans la commande "tr" par l'utilisateur et les afficher par la suite.
22/11/2010, 15h45
matafan

Dans ce cas c'est à ton programme (le process parent) de détecter les retours chariots, et d'envoyer à ce moment là les données reçues au process fils.

Note que cette approche suppose que la commande "tr" affiche ses données après chaque retour chariot, ce qui n'est pas forcément garanti. La seule façon d'être sûr du résultat et de forker une nouvelle commande "tr" pour chaque ligne.
22/11/2010, 15h58
Edw@rd

Citation:

Envoyé par matafan

Dans ce cas c'est à ton programme (le process parent) de détecter les retours chariots, et d'envoyer à ce moment là les données reçues au process fils.

Note que cette approche suppose que la commande "tr" affiche ses données après chaque retour chariot, ce qui n'est pas forcément garanti. La seule façon d'être sûr du résultat et de forker une nouvelle commande "tr" pour chaque ligne.

et comment tu peut detecter le retour chariot dans ce cas ?
22/11/2010, 16h09
nicolas.sitbon

toujours pas clair...

Citation:

Envoyé par Edw@rd

et par la suite mon programme doit intercepter tous les mots taper dans la commande "tr" par l'utilisateur et les afficher par la suite.

Que veut dire intercepter pour toi? les récupérer et empêcher leur affichage? autre chose?
taper un mot dans une commande ne veut pas dire grand chose.
voici comment fonctionne la commande tr:
elle reçoit les arguments sur sa ligne de commande qui lui indique le type de traduction a effectué. elle reçoit sur son entrée standard les données à traduires sous forme de ligne. A chaque ligne entrée, elle affiche le résultat de la traduction sur sa sortie standard.
Voilà ça ça ne changera pas, maintenant, pour ton programme, qu'attend il sur sa ligne de commande, sur son entrée standard, et quel résultat doit il produire sur sa sortie standard (si résultat il y a biensûr)?
22/11/2010, 16h31
Edw@rd

Citation:

Envoyé par nicolas.sitbon

toujours pas clair...

Que veut dire intercepter pour toi? les récupérer et empêcher leur affichage? autre chose?
taper un mot dans une commande ne veut pas dire grand chose.
voici comment fonctionne la commande tr:
elle reçoit les arguments sur sa ligne de commande qui lui indique le type de traduction a effectué. elle reçoit sur son entrée standard les données à traduires sous forme de ligne. A chaque ligne entrée, elle affiche le résultat de la traduction sur sa sortie standard.
Voilà ça ça ne changera pas, maintenant, pour ton programme, qu'attend il sur sa ligne de commande, sur son entrée standard, et quel résultat doit il produire sur sa sortie standard (si résultat il y a biensûr)?

par intercepter : juste récupérer le texte passé a tr et les afficher par la suite (tous les mots).
mon programme juste lance un processus avec le tr et n'attend rien sur son entrée standard....

Citation:

Envoyé par Edw@rd

et comment tu peut detecter le retour chariot dans ce cas ?
Code:

1 2 3 4 5 6 while ( (int c = getchar()) != EOF ) { /* Ajouter c aux données */ if (c == '\n') { /* Envoyer les données */ } }

22/11/2010, 16h35
Edw@rd
Citation:
Envoyé par matafan

Code:

1 2 3 4 5 6 while ( (int c = getchar()) != EOF ) { /* Ajouter c aux données */ if (c == '\n') { /* Envoyer les données */ } }
je suis d'accord avec ce code, mais le getchar() ici va blocké l'entrée standard....
dans mon cas je veut pas de blockage....
22/11/2010, 16h52
nicolas.sitbon

Citation:

Envoyé par Edw@rd

par intercepter : juste récupérer le texte passé a tr et les afficher par la suite (tous les mots).
mon programme juste lance un processus avec le tr et n'attend rien sur son entrée standard....

Comment fait ton programme pour intercepter si ce n'est pas sur son entrée standard?
22/11/2010, 17h03
Edw@rd

Citation:

Envoyé par nicolas.sitbon

Comment fait ton programme pour intercepter si ce n'est pas sur son entrée standard?

c'est ca ce que je cherche a resoudre...
permettre a mon programme "d'espionner" l'entrée standard du "tr" sans blocké.
22/11/2010, 17h18
nicolas.sitbon

Ok je comprends mieux le besoin et le soucis, je te conseille un peu de lecture sur les pseudos terminaux pour commencer : http://www.unixgarden.com/index.php/...es-interactifs.
22/11/2010, 17h27
Edw@rd

Citation:

Envoyé par nicolas.sitbon

Ok je comprends mieux le besoin et le soucis, je te conseille un peu de lecture sur les pseudos terminaux pour commencer : http://www.unixgarden.com/index.php/...es-interactifs.

Merci pour le lien ;)
22/11/2010, 17h59
matafan

Citation:

Envoyé par Edw@rd

je suis d'accord avec ce code, mais le getchar() ici va blocké l'entrée standard....
dans mon cas je veut pas de blockage....

Je dois mal comprendre ce que tu veux faire, mais non, il ne va pas "bloquer l'entrée standard". La lecture s'arrêtera quand l'utilisateur entrera un ^D, comme dans ton exemple.

Bon je crois que tu n'as pas compris ma méthode, donc je te donne le code. Pose des questions si tu ne comprend pas. Note que c'est juste pour l'exemple, il y a des détails à améliorer (le buf de taille fixe, et le write() qui ne suffit pas pour garantir l'envoie des données - il faudrait une boucle).

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
71
72
73
74
75
76
77
78
79
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
 
#define READ_END  0
#define WRITE_END 1
 
int
main(int argc, char **argv)
{
	int pipefd[2], c, i = 0, status;
	char buf[4096];
	pid_t pid;
 
	/* This pipe will be connected to our child's stdin */
	if (pipe(pipefd)) {
		perror("pipe");
		return 1;
	}
 
	pid = fork();
 
	if (pid == -1) { /*** Error ***/
 
		perror("fork");
		return 0;
 
	} else if (pid == 0) { /*** Child ***/
 
		/* Close write end of pipe */
		close(pipefd[WRITE_END]);
 
		/* Connect read end of pipe to stdin */
		if (-1 == dup2(pipefd[READ_END], STDIN_FILENO)) {
			perror("dup2");
			return 1;
		}
		close(pipefd[READ_END]);
 
		/* Execute user-provided command */
		execvp(argv[1], argv + 1);
		perror("execvp");
		return 1;
 
	} else { /*** Parent ***/
 
		/* Close read end of pipe */
		close(pipefd[READ_END]);
 
		/* Read data on stdin, sending them to the child process
		 * every time a newline is read */
		while ( (c = getchar()) != EOF ) {
			buf[i++] = c;
			if (c == '\n') {
				if (i != write(pipefd[WRITE_END], buf, i)) {
					perror("write");
					return 1;
				}
				i = 0;
			}
		}
		if (c != EOF) {
			perror("getchar");
			return 1;
		}
 
		/* Closing the pipe will signal EOF in the child */
		close(pipefd[WRITE_END]);
 
		/* Wait for child */
		wait(&status);
		if ( (!WIFEXITED(status)) || (WEXITSTATUS(status) != 0) ) {
			fputs("Child process terminated abnormally\n", stderr);
			return 1;
		}
	}
 
	return 0;
}

Et ça donne :

Code:

1
2
3
4
5
6
7
8
$ ./wrapper tr a-z A-Z
hello
HELLO
bonjour
BONJOUR
pomme
POMME    <- Ctrl-d
$

Citation:

Envoyé par matafan

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
71
72
73
74
75
76
77
78
79
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
 
#define READ_END  0
#define WRITE_END 1
 
int
main(int argc, char **argv)
{
	int pipefd[2], c, i = 0, status;
	char buf[4096];
	pid_t pid;
 
	/* This pipe will be connected to our child's stdin */
	if (pipe(pipefd)) {
		perror("pipe");
		return 1;
	}
 
	pid = fork();
 
	if (pid == -1) { /*** Error ***/
 
		perror("fork");
		return 0;
 
	} else if (pid == 0) { /*** Child ***/
 
		/* Close write end of pipe */
		close(pipefd[WRITE_END]);
 
		/* Connect read end of pipe to stdin */
		if (-1 == dup2(pipefd[READ_END], STDIN_FILENO)) {
			perror("dup2");
			return 1;
		}
		close(pipefd[READ_END]);
 
		/* Execute user-provided command */
		execvp(argv[1], argv + 1);
		perror("execvp");
		return 1;
 
	} else { /*** Parent ***/
 
		/* Close read end of pipe */
		close(pipefd[READ_END]);
 
		/* Read data on stdin, sending them to the child process
		 * every time a newline is read */
		while ( (c = getchar()) != EOF ) {
			buf[i++] = c;
			if (c == '\n') {
				if (i != write(pipefd[WRITE_END], buf, i)) {
					perror("write");
					return 1;
				}
				i = 0;
			}
		}
		if (c != EOF) {
			perror("getchar");
			return 1;
		}
 
		/* Closing the pipe will signal EOF in the child */
		close(pipefd[WRITE_END]);
 
		/* Wait for child */
		wait(&status);
		if ( (!WIFEXITED(status)) || (WEXITSTATUS(status) != 0) ) {
			fputs("Child process terminated abnormally\n", stderr);
			return 1;
		}
	}
 
	return 0;
}

Et ça donne :

Code:

1
2
3
4
5
6
7
8
$ ./wrapper tr a-z A-Z
hello
HELLO
bonjour
BONJOUR
pomme
POMME    <- Ctrl-d
$

ça n'est pas garanti de fonctionner avec toutes les implémentations de tr, tu dois utiliser un pseudo terminal pour ne pas te retrouver dans une position d'interblocage.

22/11/2010, 22h27
matafan

Je ne vois pas comment on pourrait avoir un interblocage ? Ca pourrait arriver si le programme père lisait la sortie du programme fils, mais ce n'est pas le cas ici. Et même dans ce cas, on pourrait régler le problème avec un poll() ou un select().
22/11/2010, 23h26
nicolas.sitbon

Citation:

Envoyé par matafan

Je ne vois pas comment on pourrait avoir un interblocage ? Ca pourrait arriver si le programme père lisait la sortie du programme fils, mais ce n'est pas le cas ici. Et même dans ce cas, on pourrait régler le problème avec un poll() ou un select().

Le problème est que tu modifies le type de stream de l'entrée standard, en l'occurrence un pipe au lieu d'un périphérique intératif style terminal. Hors la norme est très clair à ce sujet, l'entrée standard (son flux plus exactement) est fully buffered par défaut pour l'entrée standard à moins que le flux sous jacent ne soit un périphérique intéractif. Ici tu es sauver car cette implémentation de tr modifie de type de bufférisation en line buffered, c'est pour cela qu'un retour charriot valide l'entrée. Si demain tu prends une implémentation qui ne le fait pas, les données en entrées ne sont reçu (via les fonctions standard du C biensûr) qu'au moment ou le buffer est plein. Et c'est la que l'interblocage peut se produire, si tu écris un programme tiers censé manipulé ce wrapper, les données que tu vas lui envoyés ne déclencherons rien tant que le buffer ne sera pas plein, ce n'est pas ce que l'on veut, on veut valider l'entrée sur la saisie d'une ligne.
Je ne sais pas si j'ai réussi à me faire comprendre mais souvent une grosse source d'erreur dans les co-processus.
22/11/2010, 23h56
matafan

Oui je comprend, mais si tu vas pas là on peut aussi imaginer un programme qui se met fully buffered quel que soit le type d'entrée... On ne peut jamais être sûr de rien. D'ailleurs c'est bien pour ça que j'avais précisé dans mon deuxième message que la seule façon d'être sûr que chaque ligne soit traitée immédiatement, c'est de de forker un nouveau fils à chaque ligne.

Enfin c'est vrai que de ce point de vue, un pseudo-terminal c'est toujours mieux qu'un pipe.
23/11/2010, 09h30
nicolas.sitbon

En fait de base toute commande se comporte de manière interactive, et c'est généralement en lui passant un flags ou en modifiant son type de stream qu'on lui indique qu'on souhaite l'utiliser de manière non interactive (en batch par exemple). La commande tr fait de la traduction (translation devrais je dire) de texte, avec une discipline en ligne (line buffered). Il faut donc veiller à lui présenter un périphérique intéractif (avec une discipline en ligne donc) ou s'attendre à un comportement différent. Tout cela manque de normalisation je suis d'accord, la partie C a été normalisé mais pas la partie utility (commande).
Cordialement.