[Linux]comment intercepter le stdin ?

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.

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.

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.