OVH Cloud OVH Cloud

Pipe bidirectionnel

15 réponses
Avatar
JKB
Bonjour à tous,

Petite question du soir... Je sèche lamentablement sur les pipes
bidirectionnels et sur ce coup, google n'a pas été mon ami...

J'ai un programme qui fait un fork, mais j'aimerais que le père puisse
écrire sur l'entrée standard du fils et récupérer ses sorties standard et
d'erreur.

Première question, la plus simple : est-ce que tous mes descripteurs sont
bien refermés ?

J'arrive très bien à récupérer stderr et stdout dans le père, mais lorsque
je tente d'écrire depuis le père, mon truc bloque (le processus détaché par
l'appel execvp du fils prend tout le CPU). Je sèche. Voici mon code :

int pipes[2];

...

if (pipe(pipes) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

if ((pid = fork()) < 0)
{
/*
* Le fork échoue
*/

if (close(pipes[0]) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

if (close(pipes[1]) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}
else if (pid == 0)
{
#undef test
#define test
// En ôtant cette dernière ligne, on ne tient pas compte de stdin et
// ça fonctionne bien.
#ifndef test
if (close(pipes[0]) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}
#else
if (pipes[0] != STDIN_FILENO)
{
if (dup2(pipes[0], STDIN_FILENO) == -1)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}
}
#endif

if (pipes[1] != STDOUT_FILENO)
{
if (dup2(pipes[1], STDOUT_FILENO) == -1)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}
}

if (pipes[1] != STDERR_FILENO)
{
if (dup2(pipes[1], STDERR_FILENO) == -1)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}
}

if (nombre_arguments != 0)
{
execvp(arguments[0], arguments);
}
else
{
exit(EXIT_SUCCESS);
}

exit(EXIT_FAILURE);
}
else
{
#ifndef test
if (close(pipes[1]) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}
#else
if (write(pipes[1], "1\n", 2) != 2)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}
#endif

if (waitpid(pid, &status, 0) == -1)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

longueur_lecture = 256;
pointeur = 0;
nombre_iterations = 1;

if ((tampon = malloc((longueur_lecture + 1) *
sizeof(unsigned char))) == NULL)
{
(*s_etat_processus).erreur_systeme = d_es_allocation_memoire;
return;
}
...

Une idée ? Parce que franchement, je ne vois pas pourquoi cela ne fonctionne
pas...

Cordialement,

JKB

--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.

10 réponses

1 2
Avatar
Pascal Bourguignon
JKB writes:

Bonjour à tous,

Petite question du soir... Je sèche lamentablement sur les pipes
bidirectionnels et sur ce coup, google n'a pas été mon ami...

J'ai un programme qui fait un fork, mais j'aimerais que le père puisse
écrire sur l'entrée standard du fils et récupérer ses sorties standard et
d'erreur.


Alors il te faut DEUX tuyaux.

pipe = tuyaux ... ça s'éclairci comme ça?

On ne peut pas envoyer de la purée dans les deux trous d'un tuyau.
On l'envoit dans un trou et ça sort de l'autre.


Un premier tuyaux va du père au fils, et
un second tuyaux va du fils au père.


--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.

Avatar
JKB
Le 30-09-2005, à propos de
Re: Pipe bidirectionnel,
Pascal Bourguignon écrivait dans fr.comp.os.unix :
JKB writes:

Bonjour à tous,

Petite question du soir... Je sèche lamentablement sur les pipes
bidirectionnels et sur ce coup, google n'a pas été mon ami...

J'ai un programme qui fait un fork, mais j'aimerais que le père puisse
écrire sur l'entrée standard du fils et récupérer ses sorties standard et
d'erreur.


Alors il te faut DEUX tuyaux.

pipe = tuyaux ... ça s'éclairci comme ça?


Merci pour la traduction. Si je pose une question qui vous paraît un peu
bête, c'est simplement parce que les pages du manuel ne sont pas claires du
tout (et aussi parce que je suis physicien de formation et non
informaticien).

JKB


Avatar
Pascal Bourguignon
JKB writes:

Le 30-09-2005, à propos de
Re: Pipe bidirectionnel,
Pascal Bourguignon écrivait dans fr.comp.os.unix :
JKB writes:

Bonjour à tous,

Petite question du soir... Je sèche lamentablement sur les pipes
bidirectionnels et sur ce coup, google n'a pas été mon ami...

J'ai un programme qui fait un fork, mais j'aimerais que le père puisse
écrire sur l'entrée standard du fils et récupérer ses sorties standard et
d'erreur.


Alors il te faut DEUX tuyaux.

pipe = tuyaux ... ça s'éclairci comme ça?


Merci pour la traduction. Si je pose une question qui vous paraît un peu
bête, c'est simplement parce que les pages du manuel ne sont pas claires du
tout (et aussi parce que je suis physicien de formation et non
informaticien).


Je voulais ajouter: un pipe bidirectionnel, ça n'existe pas.
Les pipes unix sont unidirectionnels.

--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.



Avatar
R12y
J'ai un programme qui fait un fork, mais j'aimerais que le père puisse
écrire sur l'entrée standard du fils et récupérer ses sorties standard et
d'erreur.
Alors il te faut DEUX tuyaux.

pipe = tuyaux ... ça s'éclairci comme ça?
Merci pour la traduction. Si je pose une question qui vous paraît un peu

bête, c'est simplement parce que les pages du manuel ne sont pas claires du
tout (et aussi parce que je suis physicien de formation et non
informaticien).


N'es tu pas l'inventeur de RPL/2? C'est suffisant pour être informaticien
ça. J'en connais qui le sont sans même avoir rien inventé :-)

Fvaba har cvcr ovqverpgvbaaryyr, çn cbheenvg êger ha 42+27

(et zut, il ne rot13 pas les chiffres...)

Follow up to la buvette.

--
SPIP, phpNuke, Plone, opengroupware... c'est bien
CPS c'est mieux: http://www.cps-project.org/
Hébergement de sites CPS: http://www.objectis.org/



Avatar
Alain
On Sat, 01 Oct 2005 15:27:25 +0200
Pascal Bourguignon [Pascal] wrote:

[...]
Pascal> Je voulais ajouter: un pipe bidirectionnel, ça n'existe pas.
Pascal> Les pipes unix sont unidirectionnels.

mais si ca existe !

sur mon FreeBSD, pipe(2) dit:

The pipe() system call creates a pipe, which is an object allowing bidi-
rectional data flow, and allocates a pair of file descriptors.
[...]
The bidirectional nature of this implementation of pipes is not portable
to older systems, so it is recommended to use the convention for using
the endpoints in the traditional manner when using a pipe in one direc-
tion.

et il me semble qu'on peut faire ca ausi sur les systemes qui implementent
les pipes avec des streams.

--
Alain
Avatar
Pascal Bourguignon
Alain writes:

On Sat, 01 Oct 2005 15:27:25 +0200
Pascal Bourguignon [Pascal] wrote:

[...]
Pascal> Je voulais ajouter: un pipe bidirectionnel, ça n'existe pas.
Pascal> Les pipes unix sont unidirectionnels.

mais si ca existe !

sur mon FreeBSD, pipe(2) dit:

The pipe() system call creates a pipe, which is an object allowing bidi-
rectional data flow, and allocates a pair of file descriptors.
[...]
The bidirectional nature of this implementation of pipes is not portable
to older systems, so it is recommended to use the convention for using
the endpoints in the traditional manner when using a pipe in one direc-
tion.

et il me semble qu'on peut faire ca ausi sur les systemes qui implementent
les pipes avec des streams.


Hors de POSIX, point de salut! Non portable = inexistant.


--
__Pascal Bourguignon__ http://www.informatimago.com/

This is a signature virus. Add me to your signature and help me to live

Avatar
Eric Levenez
Le 1/10/05 15:27, dans , « Pascal
Bourguignon » a écrit :

Je voulais ajouter: un pipe bidirectionnel, ça n'existe pas.
Les pipes unix sont unidirectionnels.


Non, les pipes basés sur les STREAMS sont bidirectionnels.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Avatar
Alain
On Sat, 01 Oct 2005 17:47:48 +0200
Pascal Bourguignon [Pascal] wrote:

[...]
Pascal> Hors de POSIX, point de salut! Non portable = inexistant.

je pense que c'est une très mauvaise approche, connaître
certaines spécificités peu se réveler très utile, surtout lorsque
l'on doit "debugger" certaines applications.

--
Alain
Avatar
Pascal Bourguignon
Alain writes:
On Sat, 01 Oct 2005 17:47:48 +0200
Pascal Bourguignon [Pascal] wrote:

[...]
Pascal> Hors de POSIX, point de salut! Non portable = inexistant.

je pense que c'est une très mauvaise approche, connaître
certaines spécificités peu se réveler très utile, surtout lorsque
l'on doit "debugger" certaines applications.


Oui, bien sur. Mais ça dépend de l'environnement. Quand on travaille
sur certains projets qui durent plus d'une semaine, il vaut mieux
éviter car le matériel et le système a le temps de changer trois ou
quatre fois avant la fin du projet... Ou sinon, on se retrouve comme
la NASA à faire les dépotoirs pour trouver des vieux microprocesseurs
de rechange.


--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.

Avatar
Alain
On Sun, 02 Oct 2005 15:52:03 +0200
Pascal Bourguignon [Pascal] wrote:

Pascal> Alain writes:
Pascal> > On Sat, 01 Oct 2005 17:47:48 +0200
Pascal> > Pascal Bourguignon [Pascal] wrote:
Pascal> >
Pascal> > [...]
Pascal> > Pascal> Hors de POSIX, point de salut! Non portable = inexistant.
Pascal> >
Pascal> > je pense que c'est une très mauvaise approche, connaître
Pascal> > certaines spécificités peu se réveler très utile, surtout lorsque
Pascal> > l'on doit "debugger" certaines applications.
Pascal>
Pascal> Oui, bien sur. Mais ça dépend de l'environnement. Quand on travaille
Pascal> sur certains projets qui durent plus d'une semaine, il vaut mieux
Pascal> éviter car le matériel et le système a le temps de changer trois ou
Pascal> quatre fois avant la fin du projet... Ou sinon, on se retrouve comme

Je n'ai pas parlé d'utiliser ces spécificitées mais de les connaitre,
ca fait une sacrée nuance ;-P

Après, ce n'est pas en ignorant ces points de divergences que tu va
pouvoir changer plus facilement d'environnement au cours de la
vie de ton logiciel, au contraire.

Enfin tous les standards evoluent, ce qui est POSIX aujourd'hui ne l'était
pas forcément il y a quelques années. Il est donc également bon de savoir
faire la différence entre les différentes versions de ces standards.
Surtout le jour ou on te demande de faire marcher ton soft sur de vieux
systemes ...

Bref tout ca pour dire que je pense qu'il faut au contraire etre au courant
des differents standards, de leur evolutions ainsi que de leurs differentes
implementations.

--
Alain
1 2