comment savoir si des données sont attendues en stdin ?
20 réponses
Kobayashi
Bonjour à tous,
J'ai un programme fortran auquel je ne peux
pas toucher qui lit des données sur l'entrée
standard, fait des traitements plus ou moins
longs, puis attend des nouvelles données sur
l'entrée standard. J'aimerais pouvoir savoir
quand des données sont attendues (pour savoir
que le traitement précédent est terminé) ...
Un petit exemple :
PROGRAM MAIN
WRITE(6,*)'Enter the number of seconds to sleep ...'
READ(5,*)NUMBER
WRITE(6,*)'Sleeping for ',NUMBER,'seconds'
DO I=0,NUMBER-1
CALL SLEEP(1)
WRITE(6,*)I+1
ENDDO
WRITE(6,*)'Enter a number ...'
READ(5,*)NUMBER
WRITE(6,*)'Number is: ',NUMBER
END
J'aimerais pouvoir lancer ce programme par une
manière quelconque (system, fork, ...) et avoir
un moyen de savoir quand le programme en est aux
lignes "READ" en interrogeant je ne sais quoi
(un super pipe, un fichier de /proc, ...). En gros,
je veux quelque chose qui me réponde 1 en arrivant
au premier READ, 0 pendant toute la boucle avec
les sleep, puis 1 en arrivant au second READ.
Je cherche, je cherche mais sans trouver pour le
moment ... Si quelqu'un a une idée !
Vous avez effectivement raison, Paul, mais en y réfléchissant, n'est-ce pas fonctionnellement équivalent ? Dans la mesure où le tampon conserve les données, j'ai du mal à concevoir une raison pour laquelle le processus qui écrit devrait attendre que son "copain" soit réellement en attente sur un read...
Par exemple si l'entrée à faire dépend des sorties... (s'il faut connaître toutes les sorties produites jusqu'à l'appel à read)
Euh... Dans ce cas-là, ne serait-on pas plutôt en attente des sorties, plutôt que de la position d'attente d'une nouvelle entrée ? A moins que la sortie soit si variable qu'il soit impossible d'en prédire la fin ?
Bruno
Lucas Levrel wrote:
Le 3 juin 2010, Bruno Tréguier a écrit :
Vous avez effectivement raison, Paul, mais en y réfléchissant,
n'est-ce pas fonctionnellement équivalent ? Dans la mesure où le
tampon conserve les données, j'ai du mal à concevoir une raison pour
laquelle le processus qui écrit devrait attendre que son "copain" soit
réellement en attente sur un read...
Par exemple si l'entrée à faire dépend des sorties... (s'il faut
connaître toutes les sorties produites jusqu'à l'appel à read)
Euh... Dans ce cas-là, ne serait-on pas plutôt en attente des sorties,
plutôt que de la position d'attente d'une nouvelle entrée ? A moins que
la sortie soit si variable qu'il soit impossible d'en prédire la fin ?
Vous avez effectivement raison, Paul, mais en y réfléchissant, n'est-ce pas fonctionnellement équivalent ? Dans la mesure où le tampon conserve les données, j'ai du mal à concevoir une raison pour laquelle le processus qui écrit devrait attendre que son "copain" soit réellement en attente sur un read...
Par exemple si l'entrée à faire dépend des sorties... (s'il faut connaître toutes les sorties produites jusqu'à l'appel à read)
Euh... Dans ce cas-là, ne serait-on pas plutôt en attente des sorties, plutôt que de la position d'attente d'une nouvelle entrée ? A moins que la sortie soit si variable qu'il soit impossible d'en prédire la fin ?
Bruno
Paul Gaborit
À (at) Thu, 03 Jun 2010 09:08:03 +0200, Bruno Tréguier écrivait (wrote):
Vous avez effectivement raison, Paul, mais en y réfléchissant, n'est-ce pas fonctionnellement équivalent ? Dans la mesure où le tampon conserve les données, j'ai du mal à concevoir une raison pour laquelle le processus qui écrit devrait attendre que son "copain" soit réellement en attente sur un read... Mais Kobayashi peut peut-être nous éclairer là-dessus ?
L'exemple classique est la demande d'un mot de passe. C'est le cas standard d'utilisation de 'expect'.
Dans le cas qui nous concerne ici, je ne sais pas... Peut-être que la donnée à fournir dépend des sorties du programme et qu'il n'y a pas de moyen de savoir quand ces sortie sont terminées (sauf lorsqu'on sait que le programme attend de lire quelque chose...).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 03 Jun 2010 09:08:03 +0200,
Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> écrivait (wrote):
Vous avez effectivement raison, Paul, mais en y réfléchissant,
n'est-ce pas fonctionnellement équivalent ? Dans la mesure où le
tampon conserve les données, j'ai du mal à concevoir une raison pour
laquelle le processus qui écrit devrait attendre que son "copain" soit
réellement en attente sur un read... Mais Kobayashi peut peut-être
nous éclairer là-dessus ?
L'exemple classique est la demande d'un mot de passe. C'est le cas
standard d'utilisation de 'expect'.
Dans le cas qui nous concerne ici, je ne sais pas... Peut-être que la
donnée à fournir dépend des sorties du programme et qu'il n'y a pas de
moyen de savoir quand ces sortie sont terminées (sauf lorsqu'on sait que
le programme attend de lire quelque chose...).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 03 Jun 2010 09:08:03 +0200, Bruno Tréguier écrivait (wrote):
Vous avez effectivement raison, Paul, mais en y réfléchissant, n'est-ce pas fonctionnellement équivalent ? Dans la mesure où le tampon conserve les données, j'ai du mal à concevoir une raison pour laquelle le processus qui écrit devrait attendre que son "copain" soit réellement en attente sur un read... Mais Kobayashi peut peut-être nous éclairer là-dessus ?
L'exemple classique est la demande d'un mot de passe. C'est le cas standard d'utilisation de 'expect'.
Dans le cas qui nous concerne ici, je ne sais pas... Peut-être que la donnée à fournir dépend des sorties du programme et qu'il n'y a pas de moyen de savoir quand ces sortie sont terminées (sauf lorsqu'on sait que le programme attend de lire quelque chose...).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
À (at) Thu, 03 Jun 2010 18:18:47 +0200, Éric Lévénez écrivait (wrote):
Si on a le contrôle des 2 programmes,
Si j'ai bien compris, c'est le point clé : le programme de calcul (en Fortran mais ça n'a pas d'importance) existe déjà et n'est pas modifiable.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 03 Jun 2010 18:18:47 +0200,
Éric Lévénez <usenet@levenez.com> écrivait (wrote):
Si on a le contrôle des 2 programmes,
Si j'ai bien compris, c'est le point clé : le programme de calcul (en
Fortran mais ça n'a pas d'importance) existe déjà et n'est pas
modifiable.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 03 Jun 2010 18:18:47 +0200, Éric Lévénez écrivait (wrote):
Si on a le contrôle des 2 programmes,
Si j'ai bien compris, c'est le point clé : le programme de calcul (en Fortran mais ça n'a pas d'importance) existe déjà et n'est pas modifiable.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Nicolas George
Kobayashi wrote in message <4c07e3b1$0$9142$:
C'est exactement cela ! Nous avons un code fortran non modifiable qui, dans sa conception, est piloté de manière interactive. On le lance, il s'initialise, attends des commandes/données, fait des traitements, attends d'autres commandes/données, etc. Et la seule façon de savoir que les traitements sont terminés est de constater que le code est en mode attente de commandes/données ... On nous demande d'écrire de jolies boites de dialogue pour piloter le code mais sans le modifier.
Quel est le comportement du programme fortran si on lui envoie une commande qu'il ne comprend pas, du genre « blah » ?
Kobayashi wrote in message <4c07e3b1$0$9142$426a74cc@news.free.fr>:
C'est exactement cela ! Nous avons un code fortran non modifiable
qui, dans sa conception, est piloté de manière interactive. On le
lance, il s'initialise, attends des commandes/données, fait des
traitements, attends d'autres commandes/données, etc. Et la seule
façon de savoir que les traitements sont terminés est de constater
que le code est en mode attente de commandes/données ... On nous
demande d'écrire de jolies boites de dialogue pour piloter le code
mais sans le modifier.
Quel est le comportement du programme fortran si on lui envoie une commande
qu'il ne comprend pas, du genre « blah » ?
C'est exactement cela ! Nous avons un code fortran non modifiable qui, dans sa conception, est piloté de manière interactive. On le lance, il s'initialise, attends des commandes/données, fait des traitements, attends d'autres commandes/données, etc. Et la seule façon de savoir que les traitements sont terminés est de constater que le code est en mode attente de commandes/données ... On nous demande d'écrire de jolies boites de dialogue pour piloter le code mais sans le modifier.
Quel est le comportement du programme fortran si on lui envoie une commande qu'il ne comprend pas, du genre « blah » ?
Kobayashi
Le 03/06/2010 20:59, Nicolas George a écrit :
Kobayashi wrote in message<4c07e3b1$0$9142$:
C'est exactement cela ! Nous avons un code fortran non modifiable qui, dans sa conception, est piloté de manière interactive. On le lance, il s'initialise, attends des commandes/données, fait des traitements, attends d'autres commandes/données, etc. Et la seule façon de savoir que les traitements sont terminés est de constater que le code est en mode attente de commandes/données ... On nous demande d'écrire de jolies boites de dialogue pour piloter le code mais sans le modifier.
Quel est le comportement du programme fortran si on lui envoie une commande qu'il ne comprend pas, du genre « blah » ?
Pas bête !!! Je suis sur autre chose demain mais j'essaierai dès lundi ... Merci encore pour cette piste originale !
Le 03/06/2010 20:59, Nicolas George a écrit :
Kobayashi wrote in message<4c07e3b1$0$9142$426a74cc@news.free.fr>:
C'est exactement cela ! Nous avons un code fortran non modifiable
qui, dans sa conception, est piloté de manière interactive. On le
lance, il s'initialise, attends des commandes/données, fait des
traitements, attends d'autres commandes/données, etc. Et la seule
façon de savoir que les traitements sont terminés est de constater
que le code est en mode attente de commandes/données ... On nous
demande d'écrire de jolies boites de dialogue pour piloter le code
mais sans le modifier.
Quel est le comportement du programme fortran si on lui envoie une commande
qu'il ne comprend pas, du genre « blah » ?
Pas bête !!! Je suis sur autre chose demain mais
j'essaierai dès lundi ... Merci encore pour cette
piste originale !
C'est exactement cela ! Nous avons un code fortran non modifiable qui, dans sa conception, est piloté de manière interactive. On le lance, il s'initialise, attends des commandes/données, fait des traitements, attends d'autres commandes/données, etc. Et la seule façon de savoir que les traitements sont terminés est de constater que le code est en mode attente de commandes/données ... On nous demande d'écrire de jolies boites de dialogue pour piloter le code mais sans le modifier.
Quel est le comportement du programme fortran si on lui envoie une commande qu'il ne comprend pas, du genre « blah » ?
Pas bête !!! Je suis sur autre chose demain mais j'essaierai dès lundi ... Merci encore pour cette piste originale !
Jean-Marc Bourguet
Kobayashi writes:
C'est exactement cela ! Nous avons un code fortran non modifiable qui, dans sa conception, est piloté de manière interactive. On le lance, il s'initialise, attends des commandes/données, fait des traitements, attends d'autres commandes/données, etc. Et la seule façon de savoir que les traitements sont terminés est de constater que le code est en mode attente de commandes/données ... On nous demande d'écrire de jolies boites de dialogue pour piloter le code mais sans le modifier.
Et celui qui utilise le programme de facon interactive, comment sait-il qu'il doit fournir les donnees?
Si le probleme est qu'il manque des flush apres un prompt quand la sortie est capturee alors qu'ils y sont quand on sort vers un terminal, la solution est l'utilisation de pseudo-terminaux plutot que de pipes pour communiquer avec lui.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Kobayashi <kobayashi@netcourrier.com> writes:
C'est exactement cela ! Nous avons un code fortran non modifiable
qui, dans sa conception, est piloté de manière interactive. On le
lance, il s'initialise, attends des commandes/données, fait des
traitements, attends d'autres commandes/données, etc. Et la seule
façon de savoir que les traitements sont terminés est de constater
que le code est en mode attente de commandes/données ... On nous
demande d'écrire de jolies boites de dialogue pour piloter le code
mais sans le modifier.
Et celui qui utilise le programme de facon interactive, comment sait-il
qu'il doit fournir les donnees?
Si le probleme est qu'il manque des flush apres un prompt quand la sortie
est capturee alors qu'ils y sont quand on sort vers un terminal, la
solution est l'utilisation de pseudo-terminaux plutot que de pipes pour
communiquer avec lui.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est exactement cela ! Nous avons un code fortran non modifiable qui, dans sa conception, est piloté de manière interactive. On le lance, il s'initialise, attends des commandes/données, fait des traitements, attends d'autres commandes/données, etc. Et la seule façon de savoir que les traitements sont terminés est de constater que le code est en mode attente de commandes/données ... On nous demande d'écrire de jolies boites de dialogue pour piloter le code mais sans le modifier.
Et celui qui utilise le programme de facon interactive, comment sait-il qu'il doit fournir les donnees?
Si le probleme est qu'il manque des flush apres un prompt quand la sortie est capturee alors qu'ils y sont quand on sort vers un terminal, la solution est l'utilisation de pseudo-terminaux plutot que de pipes pour communiquer avec lui.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Dominique MICOLLET
Je dérive un nouveau fil sur une remarque d'un contributeur
Jean-Marc Bourguet wrote:
Si le probleme est qu'il manque des flush apres un prompt quand la sortie est capturee alors qu'ils y sont quand on sort vers un terminal, la solution est l'utilisation de pseudo-terminaux plutot que de pipes pour communiquer avec lui.
Si je comprends bien ce que vous écrivez, le comportement du flux de sortie d'un programme peut être influencé par le comportement du flux d'entrée d'un autre. Pourriez-vous éclairer ma lanterne quant au mécanisme mis en oeuvre pour ce faire ? J'imagine que ça se fait au niveau noyau, mais je ne vois pas clairement comment.
Cordialement. -- Dominique MICOLLET Adresse email : enlever deux francs
Je dérive un nouveau fil sur une remarque d'un contributeur
Jean-Marc Bourguet wrote:
Si le probleme est qu'il manque des flush apres un prompt quand la sortie
est capturee alors qu'ils y sont quand on sort vers un terminal, la
solution est l'utilisation de pseudo-terminaux plutot que de pipes pour
communiquer avec lui.
Si je comprends bien ce que vous écrivez, le comportement du flux de sortie
d'un programme peut être influencé par le comportement du flux d'entrée
d'un autre.
Pourriez-vous éclairer ma lanterne quant au mécanisme mis en oeuvre pour ce
faire ? J'imagine que ça se fait au niveau noyau, mais je ne vois pas
clairement comment.
Cordialement.
--
Dominique MICOLLET
Adresse email : enlever deux francs
Je dérive un nouveau fil sur une remarque d'un contributeur
Jean-Marc Bourguet wrote:
Si le probleme est qu'il manque des flush apres un prompt quand la sortie est capturee alors qu'ils y sont quand on sort vers un terminal, la solution est l'utilisation de pseudo-terminaux plutot que de pipes pour communiquer avec lui.
Si je comprends bien ce que vous écrivez, le comportement du flux de sortie d'un programme peut être influencé par le comportement du flux d'entrée d'un autre. Pourriez-vous éclairer ma lanterne quant au mécanisme mis en oeuvre pour ce faire ? J'imagine que ça se fait au niveau noyau, mais je ne vois pas clairement comment.
Cordialement. -- Dominique MICOLLET Adresse email : enlever deux francs
Jean-Marc Bourguet
Dominique MICOLLET writes:
Je dérive un nouveau fil sur une remarque d'un contributeur
Jean-Marc Bourguet wrote:
> Si le probleme est qu'il manque des flush apres un prompt quand la sortie > est capturee alors qu'ils y sont quand on sort vers un terminal, la > solution est l'utilisation de pseudo-terminaux plutot que de pipes pour > communiquer avec lui.
Si je comprends bien ce que vous écrivez, le comportement du flux de sortie d'un programme peut être influencé par le comportement du flux d'entrée d'un autre. Pourriez-vous éclairer ma lanterne quant au mécanisme mis en oeuvre pour ce faire ? J'imagine que ça se fait au niveau noyau, mais je ne vois pas clairement comment.
On peut detecter (avec isatty()) si un descripteur est dirige vers un terminal ou non. Un programme peut alors avoir un comportement different -- par exemple la libc utilise cela pour ne pas bufferiser stdout par bloc.
Comme a ma connaissance ce probleme est le probleme numero 1 quand on essaie de controler un programme concu pour etre interactif par un autre et que je n'ai pas vu le signaler (a part indirectement par une mention a expect, mais pour faire le lien il faut connaitre et la source du probleme et le fait que expect utilise des pseuso-terminaux pour l'eviter), j'emets l'hypothese que c'est le cas pour l'OP.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je dérive un nouveau fil sur une remarque d'un contributeur
Jean-Marc Bourguet wrote:
> Si le probleme est qu'il manque des flush apres un prompt quand la sortie
> est capturee alors qu'ils y sont quand on sort vers un terminal, la
> solution est l'utilisation de pseudo-terminaux plutot que de pipes pour
> communiquer avec lui.
Si je comprends bien ce que vous écrivez, le comportement du flux de sortie
d'un programme peut être influencé par le comportement du flux d'entrée
d'un autre.
Pourriez-vous éclairer ma lanterne quant au mécanisme mis en oeuvre pour ce
faire ? J'imagine que ça se fait au niveau noyau, mais je ne vois pas
clairement comment.
On peut detecter (avec isatty()) si un descripteur est dirige vers
un terminal ou non. Un programme peut alors avoir un comportement
different -- par exemple la libc utilise cela pour ne pas bufferiser
stdout par bloc.
Comme a ma connaissance ce probleme est le probleme numero 1 quand on
essaie de controler un programme concu pour etre interactif par un autre et
que je n'ai pas vu le signaler (a part indirectement par une mention a
expect, mais pour faire le lien il faut connaitre et la source du probleme
et le fait que expect utilise des pseuso-terminaux pour l'eviter), j'emets
l'hypothese que c'est le cas pour l'OP.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je dérive un nouveau fil sur une remarque d'un contributeur
Jean-Marc Bourguet wrote:
> Si le probleme est qu'il manque des flush apres un prompt quand la sortie > est capturee alors qu'ils y sont quand on sort vers un terminal, la > solution est l'utilisation de pseudo-terminaux plutot que de pipes pour > communiquer avec lui.
Si je comprends bien ce que vous écrivez, le comportement du flux de sortie d'un programme peut être influencé par le comportement du flux d'entrée d'un autre. Pourriez-vous éclairer ma lanterne quant au mécanisme mis en oeuvre pour ce faire ? J'imagine que ça se fait au niveau noyau, mais je ne vois pas clairement comment.
On peut detecter (avec isatty()) si un descripteur est dirige vers un terminal ou non. Un programme peut alors avoir un comportement different -- par exemple la libc utilise cela pour ne pas bufferiser stdout par bloc.
Comme a ma connaissance ce probleme est le probleme numero 1 quand on essaie de controler un programme concu pour etre interactif par un autre et que je n'ai pas vu le signaler (a part indirectement par une mention a expect, mais pour faire le lien il faut connaitre et la source du probleme et le fait que expect utilise des pseuso-terminaux pour l'eviter), j'emets l'hypothese que c'est le cas pour l'OP.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Jean-Marc Bourguet writes:
Comme a ma connaissance ce probleme est le probleme numero 1 quand on essaie de controler un programme concu pour etre interactif par un autre
En passant, le probleme numero 2 est l'ouverture par le programme controlle de /dev/tty pour eviter les redirections. L'utilisation de pseudo-terminaux permet aussi de le resoudre. Mais les symptomes decrits ici ne correspondent pas.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet <jm@bourguet.org> writes:
Comme a ma connaissance ce probleme est le probleme numero 1 quand on
essaie de controler un programme concu pour etre interactif par un autre
En passant, le probleme numero 2 est l'ouverture par le programme
controlle de /dev/tty pour eviter les redirections. L'utilisation
de pseudo-terminaux permet aussi de le resoudre. Mais les symptomes
decrits ici ne correspondent pas.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Comme a ma connaissance ce probleme est le probleme numero 1 quand on essaie de controler un programme concu pour etre interactif par un autre
En passant, le probleme numero 2 est l'ouverture par le programme controlle de /dev/tty pour eviter les redirections. L'utilisation de pseudo-terminaux permet aussi de le resoudre. Mais les symptomes decrits ici ne correspondent pas.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Dominique MICOLLET
Jean-Marc Bourguet wrote:
On peut detecter (avec isatty()) si un descripteur est dirige vers un terminal ou non. Un programme peut alors avoir un comportement different -- par exemple la libc utilise cela pour ne pas bufferiser stdout par bloc.
Toujours pour ma culture personnelle et pour m'assurer si je comprends bien, isatty est donc à mettre en oeuvre coté producteur : on flushe en sortie uniquement si isatty renvoie 1.
Cordialement.
-- Dominique MICOLLET Adresse email : enlever deux francs
Jean-Marc Bourguet wrote:
On peut detecter (avec isatty()) si un descripteur est dirige vers
un terminal ou non. Un programme peut alors avoir un comportement
different -- par exemple la libc utilise cela pour ne pas bufferiser
stdout par bloc.
Toujours pour ma culture personnelle et pour m'assurer si je comprends bien,
isatty est donc à mettre en oeuvre coté producteur : on flushe en sortie
uniquement si isatty renvoie 1.
Cordialement.
--
Dominique MICOLLET
Adresse email : enlever deux francs
On peut detecter (avec isatty()) si un descripteur est dirige vers un terminal ou non. Un programme peut alors avoir un comportement different -- par exemple la libc utilise cela pour ne pas bufferiser stdout par bloc.
Toujours pour ma culture personnelle et pour m'assurer si je comprends bien, isatty est donc à mettre en oeuvre coté producteur : on flushe en sortie uniquement si isatty renvoie 1.
Cordialement.
-- Dominique MICOLLET Adresse email : enlever deux francs
