Bonjour,  
 
Ayant pour projet le codage d'un interpréteur de commandes unix, nous sommes confrontes à un petit problème.
Nous arrivons à exécuter une commande contenant un pipe, du genre de ls | less, mais nous devons réussir à gérer les pipes en nombre théoriquement infini, et nous bloquons sur la façon de faire.
La solution la plus évidente serait de faire ceci en récursif, mais nous ne sommes pas à l'aise avec ceci, et nous n'avons plus énormément de temps pour faire des tests en utilisant ce principe afin de l'assimiler.
Nous aimerions simplement, mon groupe et moi même, que l'on nous explique brièvement de quelle façon nous pourrions procéder, récursivement ou non, pour traiter ce problème.
Je peux fournir de plus amples informations sur la structure du code, ou quoi que ce soit d'autre
Merci d'avance pour tout éclaircissement par rapport à ces multipipes.

Bonsoir,
 
Non, je ne crois pas que ce soit du récursif, mais plutôt de l'itératif.
La récursivité sert à explorer des structures arborescente.
Or ici, sauf erreur, il n'y a pas d'arbre, juste une succession de traitements qui s’enchaînent avec la sortie de l'un qui devient l'entrée de l'autre.
 
Donc, un algorithme serait :
 
Boucle sur chaque morceau situé entre le début de la ligne ou le début d'un pipe, jusqu'au pipe suivant ou jusqu'à la fin de ligne
{
  Lance le programme indiqué au début du morceau
  en lui donnant les paramètres qui suivent
  en lui donnant en entrée (stdin) le paramètre qui suit le signe inférieur, ou les données qui viennent d'un fichier temporaire si le morceau commence par un pipe
  en dirigeant sa sortie (stdout) vers l'écran, ou vers ce qui suit le signe supérieur, ou vers un fichier temporaire si le morceau se termine par un pipe
}

Bonsoir, est-on oblige de passer par un fichier temporarire ?
Du coup il faudrait open un fichier, rentrer son fd en sortie du pipe, et donner ce fd en entree du pipe suivant ?

Je confirme, pour avoir eu un projet à la con de ce type (a Epitech ) le récursif est définitivement une mauvaise idée, ça engendre des emmerdes qui vont au delà de la simple erreur de conception (notamment on ne peut pas récupérer le code d'erreur du processus qu'on a lancé en récursif vu qu'alors on se retrouve dans le fils d'un fils d'un fils ... )

La meilleure solution est donc une solution qui se rapproche  de ce que dit billgatesanonym, à savoir une boucle qui va forker, lancer le programme, créer le pipe, et à la prochaine itération vous vous servez de l'entrée du pipe créé précédemment etc ...