Lecture sur stdout - Page 1

Y a-t-i un moyen de lire ce qui se passe sur stdout ? Par exemple, j'exécute pedrom::system(flags). Dois-je faire une redirection vers un fichier temporaire, ou puis-je lire directement ce qui sort de stdout ? pedrom::stdout représente-t-il cet emplacement ?
Mieux : puis-je rediriger pedrom::stdout vers une emplacement de mon choix (genre un stack frame) puis y lire le résultat de pedrom::system ?

Avec fread, fgets ou fgetc ça ne fonctionne pas ?

En y réfléchissant, je ne comprends pas pourquoi ton programme a besoin de lire ce qu'il se passe sur stdout. A moins de bidouiller des trucs avec des threads (mais je ne crois pas que pedrom puisse faire ça, si ?), tu n'auras pas grand chose à lire.

sauf si, comme dit, mon programme fait un pedrom::system(machin-chose) et qu'il veut lire ce qui s'y passe, parce qu'il n'y a pas de fonctions d'accès internes pour faire autrement.
Et je crois que tous les f* ont besoin d'un fichier ouvert pour fonctionner.

PpHd, s'il te plait ?

Tu n'as pas d'autres choix que de faire un system("ma commande > monfichiertmp"); suivi d'un fopen de ce fichier.

Les pipes, c'est légèrement ch**** à implémenter...

PpHd (./6) :
Tu n'as pas d'autres choix que de faire un system("ma commande > monfichiertmp"); suivi d'un fopen de ce fichier.

Ok. Mais j'utilisais pas fopen dans la première version. J'utilisais pedrom::tmpnam, et j'allais lire dedans avec un SymFind etc...

Ca serait possible de faire une fonction d'accès au flag implantée dans PedroM ? pedrom::getflags ? Si ça t'intéresse, je bosse dessus et te fais une proposition. Ca m'a l'air relativement simple à implémenter en plus.

Lionel Debroux (./7) :
Les pipes, c'est légèrement ch**** à implémenter...

Je les code en dur, comme ça j'y vois que du feu, genre pedrom::system("flags | grep OffSwitch > xxx")

voilà :
StringSection FlagsStr, """flags|grep %s>%s"""

Folco (./8) :
Ca serait possible de faire une fonction d'accès au flag implantée dans PedroM ? pedrom::getflags ? Si ça t'intéresse, je bosse dessus et te fais une proposition.

Le problème est que je ne suis pas sûr que ca interresse d'autres personnes que toi, dans ton programme de configuration.
Si c'était le cas, je l'aurais fait. Mais là, je pense que laisser l'interface via system est suffisante.
Ensuite, si tu en as vraiment besoin, je ne dis pas non.

Ok. Je voyais ça juste par rapport à la place que ça prend d'y accéder. C'est sûr que si je suis le seul à le faire, autant que le poide de ce code soit dans mon programme.

Ah si, je viens de me rendre compte d'un cas, dans un de mes propres programmes ^^ J'utilise 2nd-switch dans graytool pour passer d'un poitn à l'autre d'un curseur ou d'une ligne. Si le flag GetKeySwich est mis, le programme devient limite inutilisable (obligé de quitter un shell en permanence quand on dessine ^^). Donc oui, des fonctions d'accès rapide seraient pas mal ^^

en entrée :
OrgFlag = GetFlag(GetKeySwitch);
SetFlag(GetKeySwitch,0);
ou
OrgFlag = SetFlag(GetKeySwitch,0);

puis en sortie :
SetFlag(GetKeySwich,OrgFlag);

Pète couille.
Tu peux pas choisir une autre touche ?

Bon, ok, si ça te fait tant chier que ça C'est juste que ça me paraissait très intuitif comme choix de touche ^^ (et que c'est ce que j'utilise d'habitude. c'est la troisième fois que je code ce soft, une fois en basic avec flib, une fois en asm, une fois en C. mais jamais releasé )