J'ai un programme source fermé qui imprime la sortie à la sortie standard. J'ai besoin d'analyser la sortie. J'ai donc redirigé la sortie sur une FIFO (à partir duquel je peux lire dans le processus parent qui utilise les fourches et exécutant le binaire) à l'aide du DUP2, puis exécutant le programme. Le problème est que les appels FPRRTINF dans le fichier deviennent tamponnés car il écrit maintenant à un fichier.
J'ai essayé d'appeler SetVbuf avec _ionbf sur stdout avant d'appeler Exec. Mais le problème existe toujours.
Pourquoi SETVBUF ne peut-il pas aider dans mon cas?
Comment puis-je forcer la sortie à vous faire vaciller?
3 Réponses :
La seule façon dont j'ai entendu parler de cela, c'est de simuler un faux terminal au processus. C'est parce que la plupart des bibliothèques CRT n'effectueront par défaut que la mémoire tampon de ligne s'ils croient qu'elles sont attachées à un terminal interactif (dans le monde UNIX: si Cet utilitaire ressemble à un très bon endroit pour commencer. (Emprunté à un commentaire sur Trick an Application en pensant que son stdin est interactif, pas un tuyau , qui a d'autres informations utiles.) SETVBUF () ne fait aucune différence car il modifie l'état de la partie de la bibliothèque d'exécution C, ne faisant pas partie du système d'exploitation. Lorsque le nouveau processus commence à courir, sa bibliothèque d'exécution C sera réinitialisée (c'est-à-dire s'il utilise un CRT du tout!)
isatté () renvoie true sur le descripteur de fichier), alors que sinon ils va tamponner dans des blocs plus gros (généralement 8 ko ou plus).
Je forcis un processus, appelez SetVbuf dans le processus enfant, puis exécutez un script shell qui exécute un autre script shell qui exécute enfin le binaire. Puis-je modifier la commande finale Exec (Bash) afin qu'elle désactive la mise en mémoire tampon d'une manière ou d'une autre.
Je répète, il est inutile d'appeler SETVBUF () avant d'exécuter - Aucun de l'état de la bibliothèque d'exécution C n'est préservé à travers Exec ()! Le processus final que vous exécressez () ne peut même pas utiliser le CRT! (Improbable mais possible.)
ok j'essaie l'approche PTY voir Stackoverflow.com/questions / 2056858 / ne peut pas-écrire-to-pty-linu x
Je suppose que vous avez quelque chose comme ceci dans votre programme (vous pouvez reproduire cela pour vos tests, je l'appelle par exemple Si vous exécutez P> isatté code> ici) $ ./isatty.expect > isatty.out
$ cat isatty.out
spawn ./isatty
0: is a TTY
1: is a TTY
L'outil code> Leduffer code> peut aider à ce problème:
Il fait partie du attendre-dev code> et peut être installé à Ubuntu en utilisant P> unbuffer ls > log.txt