Programmation Unix, fork(), exec(), dup2()

Alors voilà, je vais essayer d'aller au plus simple.

J'ai créé un programme en C qui créé un processus fils dans lequel j'effectue un exec d'un programme X ayant pour unique but des affichages basiques à l'aide de printf, ce processus fils créé à son tour un processus fils avec la même mission que son processus parent (exécuter un programme Y faisant des printf).

Alors voila mon problème : je voudrais que si l'utilisateur entre un argument lors de l'exécution de ce programme, tous les printf soient enregistrés dans des fichiers (un fichier pour les affichages du programme X et un autre pour les affichages du programme Y).

Dans le cadre d'un projet pour la fac je suis obligé de créer les fichiers dans le programme que j'exécute au début et non dans les programme appelé par les exec.
Je sais qu'il faut utiliser la fonction dup2(), j'ai essayé et en effet, cela marche uniquement pour le programme X mais le fichier du Y est vide.

Merci d'avance pour vos réponses.

Bonjour et bienvenue,

Citation:

---

Envoyé par jojodu94

Dans le cadre d'un projet pour la fac je suis obligé de créer les fichiers dans le programme que j'exécute au début et non dans les programme appelé par les exec.
Je sais qu'il faut utiliser la fonction dup2(),

---

Tu n'es pas obligé de passer par dup2(). Tu peux également conserver la trace des descripteurs de fichiers ouverts par fopen(), du style FILE *f; f = fopen("tonfichier","w+"); puis utiliser non pas printf mais fprintf en utilisant un flux de sortie de type « FILE * », lui aussi. Par exemple fprintf (out,"Ton texte");. En début de programme, en fonction de l'argument, tu affectes soit stdout, soit ton descripteur f à la variable out.

Citation:

---

j'ai essayé et en effet, cela marche uniquement pour le programme X mais le fichier du Y est vide.
Merci d'avance pour vos réponses.

---

Il y a plusieurs causes possibles à cela. Impossible d'être catégorique sans voir ton code. Il y a malgré tout deux possibilités :

• Tu fais le remplacement trop tôt. Il est évident que le dup2() doit avoir lieu dans chacun des processus qui écriront dans un fichier et non dans leur pères, car le descripteur de sortie sera forcément le numéro 1 (par convention). Donc si tu fais deux appels à dup2() vers ce descripteur, le second va écraser le premier et l'un des deux processus ne pourra jamais écrire ;
• Il est possible que tes informations soient toujours bloquées dans le buffer et qu'elles aient besoin d'un fflush() de temps en temps, sinon une mort prématurée du processus pourrait provoquer leur perte ;

D'ailleurs, si j'ai bien suivi ton raisonnement, il y aurait trois processus en tout. Il faut donc veiller à ce que le tout premier ne meure pas trop tôt.

Citation:

---

Tu n'es pas obligé de passer par dup2(). Tu peux également conserver la trace des descripteurs de fichiers ouverts par fopen(), du style FILE *f; f = fopen("tonfichier","w+"); puis utiliser non pas printf mais fprintf en utilisant un flux de sortie de type « FILE * », lui aussi. Par exemple fprintf (out,"Ton texte");. En début de programme, en fonction de l'argument, tu affectes soit stdout, soit ton descripteur f à la variable out.

---

Déja merci beaucoup,
J'ai pensé a cette alternative, mais je comprend pas comment dans le programme X (ou Y) on va se servir du fichier créé dans le programme parent (programme principal exécuté au début), en effet, si dans le programme X je fais un fprintf avec le fichier il va me dire (lors de la compilation) que le fichier n'existe pas car il est creer dans un autre programme.
Je sais pas si j'ai été assez clair :)

En fait, le fichier proprement dit n'a pas d'existence propre dans le processus lui-même : seul compte le descripteur qui t'a été renvoyé lorsqu'il a été ouvert. La destination finale des données qui sont transmises par son biais est du ressort du système d'exploitation.

Ensuite, ce qui est intéressant (et ce qui justifie dup2() entre autres) est que les fichiers ouverts sont hérités par les processus fils. Il appartient d'ailleurs à ceux-ci de refermer proprement, en début de traitement, tout ceux qu'ils n'utilisent pas.

En gros ce que je voudrais faire c'est quelque chose comme ça :

Pièce jointe 324361
Pièce jointe 324366

Au temps pour moi, j'avais fait abstraction de la clause exec… Il était un peu tard hier.

Donc, certes, les fichiers ouverts sont hérités par les processus fils lorsque tu forkes, mais ils sont bien sûr refermés au moment où tu appelles exec puisque de toutes façons, toutes les variables disparaissent également (puisque tu changes de processus et que le programme n'est plus du tout le même) et que tu ne pourrais donc conserver la trace de leur descripteurs. Il y a moyen de leur demander de ne pas le faire sous certaines conditions mais dans le cas qui t'intéresse, ça apporte plus de problème que ça n'en résout.

Dans ton cas, ce qu'il faut faire, la manière normale de le faire serait bien sûr d'ouvrir le second fichier dans le second programme exactement de la même manière que tu l'as fait dans le premier. Mais ce n'est effectivement pas les consignes de l'exercice (assez courant, au passage).

Ce qu'il va falloir faire, c'est effectivement passer par la sortie standard dans les deux cas. Donc, tu peux revenir à des printf normaux si tu le souhaites. Ensuite, il va falloir rediriger la sortie standard du deuxième processus APRÈS avoir forké, sinon tu es encore dans le premier, mais AVANT d'appeler exec.