J'ai une application codé en C qui doit
lancer un script PHP CLI en lui fournissant
une info et récupérer le résultat d'un traitement...
Quels sont les moyens d'y parvenir ?
- par le biais de fichiers, j'aimerai éviter car ce sont des donnée
éphémères
- par des variables d'environnement ?
Je ne peut pas passer par stdin/stdout car l'appli utilise déja ce moyen
pour
dialoguer avec une autre application.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Bourguignon
"Stan" writes:
Bonsoir,
J'ai une application codé en C qui doit lancer un script PHP CLI en lui fournissant une info et récupérer le résultat d'un traitement...
Quels sont les moyens d'y parvenir ? - par le biais de fichiers, j'aimerai éviter car ce sont des donnée éphémères - par des variables d'environnement ?
Il y a des tonnes de possibilités.
http://www.google.com/search?q=unix+IPC
Je ne peut pas passer par stdin/stdout car l'appli utilise déja ce moyen pour dialoguer avec une autre application.
Quel stdin/stdout? Il y en a une paire pour chaque _processus_!
-- __Pascal Bourguignon__ http://www.informatimago.com/ You never feed me. Perhaps I'll sleep on your face. That will sure show you.
"Stan" <none@none.invalide> writes:
Bonsoir,
J'ai une application codé en C qui doit
lancer un script PHP CLI en lui fournissant
une info et récupérer le résultat d'un traitement...
Quels sont les moyens d'y parvenir ?
- par le biais de fichiers, j'aimerai éviter car ce sont des donnée
éphémères
- par des variables d'environnement ?
Il y a des tonnes de possibilités.
http://www.google.com/search?q=unix+IPC
Je ne peut pas passer par stdin/stdout car l'appli utilise déja ce
moyen pour dialoguer avec une autre application.
Quel stdin/stdout? Il y en a une paire pour chaque _processus_!
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
J'ai une application codé en C qui doit lancer un script PHP CLI en lui fournissant une info et récupérer le résultat d'un traitement...
Quels sont les moyens d'y parvenir ? - par le biais de fichiers, j'aimerai éviter car ce sont des donnée éphémères - par des variables d'environnement ?
Il y a des tonnes de possibilités.
http://www.google.com/search?q=unix+IPC
Je ne peut pas passer par stdin/stdout car l'appli utilise déja ce moyen pour dialoguer avec une autre application.
Quel stdin/stdout? Il y en a une paire pour chaque _processus_!
-- __Pascal Bourguignon__ http://www.informatimago.com/ You never feed me. Perhaps I'll sleep on your face. That will sure show you.
Stan
"Pascal Bourguignon" a écrit dans le message de news:
"Stan" writes:
Bonsoir,
J'ai une application codé en C qui doit lancer un script PHP CLI en lui fournissant une info et récupérer le résultat d'un traitement...
Quels sont les moyens d'y parvenir ? - par le biais de fichiers, j'aimerai éviter car ce sont des donnée éphémères - par des variables d'environnement ?
Il y a des tonnes de possibilités. http://www.google.com/search?q=unix+IPC
Oui, mais beaucoup ne sont pas applicables dans mon cas ( fonction execlp + script php/cli ).
Je ne peut pas passer par stdin/stdout car l'appli utilise déja ce moyen pour dialoguer avec une autre application.
Quel stdin/stdout? Il y en a une paire pour chaque _processus_!
L'application en question est executée par xinetd et communique grace a stdin/stout avec la partie cliente. Je ne peux donc pas rediriger à nouveau ces descripteurs pour dialoguer avec le script php/cli.
-- -Stan
"Pascal Bourguignon" <pjb@informatimago.com> a écrit dans le message de
news:87vem1emlu.fsf@thalassa.informatimago.com...
"Stan" <none@none.invalide> writes:
Bonsoir,
J'ai une application codé en C qui doit
lancer un script PHP CLI en lui fournissant
une info et récupérer le résultat d'un traitement...
Quels sont les moyens d'y parvenir ?
- par le biais de fichiers, j'aimerai éviter car ce sont des donnée
éphémères
- par des variables d'environnement ?
Il y a des tonnes de possibilités.
http://www.google.com/search?q=unix+IPC
Oui, mais beaucoup ne sont pas applicables dans mon cas
( fonction execlp + script php/cli ).
Je ne peut pas passer par stdin/stdout car l'appli utilise déja ce
moyen pour dialoguer avec une autre application.
Quel stdin/stdout? Il y en a une paire pour chaque _processus_!
L'application en question est executée par xinetd et communique grace a
stdin/stout
avec la partie cliente.
Je ne peux donc pas rediriger à nouveau ces descripteurs pour dialoguer
avec le script php/cli.
"Pascal Bourguignon" a écrit dans le message de news:
"Stan" writes:
Bonsoir,
J'ai une application codé en C qui doit lancer un script PHP CLI en lui fournissant une info et récupérer le résultat d'un traitement...
Quels sont les moyens d'y parvenir ? - par le biais de fichiers, j'aimerai éviter car ce sont des donnée éphémères - par des variables d'environnement ?
Il y a des tonnes de possibilités. http://www.google.com/search?q=unix+IPC
Oui, mais beaucoup ne sont pas applicables dans mon cas ( fonction execlp + script php/cli ).
Je ne peut pas passer par stdin/stdout car l'appli utilise déja ce moyen pour dialoguer avec une autre application.
Quel stdin/stdout? Il y en a une paire pour chaque _processus_!
L'application en question est executée par xinetd et communique grace a stdin/stout avec la partie cliente. Je ne peux donc pas rediriger à nouveau ces descripteurs pour dialoguer avec le script php/cli.
-- -Stan
Harpo
Stan wrote:
L'application en question est executée par xinetd et communique grace a stdin/stout avec la partie cliente. Je ne peux donc pas rediriger à nouveau ces descripteurs pour dialoguer avec le script php/cli.
Cette application est-elle modifiable ? Si oui, il est possible de rediriger d'autres descripteurs, ou de la faire écouter sur un socket.
-- http://patrick.davalan.free.fr/
Stan wrote:
L'application en question est executée par xinetd et communique grace
a stdin/stout avec la partie cliente.
Je ne peux donc pas rediriger à nouveau ces descripteurs pour
dialoguer avec le script php/cli.
Cette application est-elle modifiable ? Si oui, il est possible de
rediriger d'autres descripteurs, ou de la faire écouter sur un socket.
L'application en question est executée par xinetd et communique grace a stdin/stout avec la partie cliente. Je ne peux donc pas rediriger à nouveau ces descripteurs pour dialoguer avec le script php/cli.
Cette application est-elle modifiable ? Si oui, il est possible de rediriger d'autres descripteurs, ou de la faire écouter sur un socket.
-- http://patrick.davalan.free.fr/
Stan
"Harpo" a écrit dans le message de news:454720f1$0$29355$
Stan wrote:
L'application en question est executée par xinetd et communique grace a stdin/stout avec la partie cliente. Je ne peux donc pas rediriger à nouveau ces descripteurs pour dialoguer avec le script php/cli.
Cette application est-elle modifiable ? Si oui, il est possible de rediriger d'autres descripteurs, ou de la faire écouter sur un socket.
Oui, j'ai les sources. Modifier d'autres descripteurs ? autre que stdin/stdout ?
Par contre l'option des sockets serait plus compliquée à mettre en oeuvre qu'un échange par fichier.
-- -Stan
"Harpo" <invalid@invalid.invalid> a écrit dans le message de
news:454720f1$0$29355$426a34cc@news.free.fr...
Stan wrote:
L'application en question est executée par xinetd et communique grace
a stdin/stout avec la partie cliente.
Je ne peux donc pas rediriger à nouveau ces descripteurs pour
dialoguer avec le script php/cli.
Cette application est-elle modifiable ? Si oui, il est possible de
rediriger d'autres descripteurs, ou de la faire écouter sur un socket.
Oui, j'ai les sources.
Modifier d'autres descripteurs ?
autre que stdin/stdout ?
Par contre l'option des sockets serait plus
compliquée à mettre en oeuvre qu'un échange par fichier.
"Harpo" a écrit dans le message de news:454720f1$0$29355$
Stan wrote:
L'application en question est executée par xinetd et communique grace a stdin/stout avec la partie cliente. Je ne peux donc pas rediriger à nouveau ces descripteurs pour dialoguer avec le script php/cli.
Cette application est-elle modifiable ? Si oui, il est possible de rediriger d'autres descripteurs, ou de la faire écouter sur un socket.
Oui, j'ai les sources. Modifier d'autres descripteurs ? autre que stdin/stdout ?
Par contre l'option des sockets serait plus compliquée à mettre en oeuvre qu'un échange par fichier.
-- -Stan
Harpo
Stan wrote:
Cette application est-elle modifiable ? Si oui, il est possible de rediriger d'autres descripteurs, ou de la faire écouter sur un socket.
Oui, j'ai les sources.
Le problème est aussi : est-ce que tu veux les maintenir ? Si l'application est maintenues, il vaut sans doute mieux voir avec celui qui maintient afin que les améliorations de part et d'autre profitent à l'autre.
Modifier d'autres descripteurs ? autre que stdin/stdout ?
d'un shell on peut rediriger les io, mais je ne suis pas guru du shell et ça me prend la tête. Si c'est l'appli lancée par inetd qui lance le script, il y a moyen d'utiliser un pipe.
Par contre l'option des sockets serait plus compliquée à mettre en oeuvre qu'un échange par fichier.
Ce n'est pas sûr et ça dépend de ce que tu veux, ça dépend de plusieurs choses : . de la responsivité souhaitée, si l'appli veut aller voir tous les jours ou toutes les 10 secondes s'il y a quelque chose pour elle, sans doute un fichier est meilleur . Pour plus de responsivité, un handler d'un signal qui lui dit qu'il y a quelque chose (si c'est le script qui envoie à l'appli) et on va chercher le fichier là ou il est convenu qu'il soit. . S'il y a un besoin de responsivité, il est peut-être préférable de passer par IPC ou par un socket qui permet que le script ne tourne pas sur la même machine. *Mais* ça dépend surtout de la manière dont est écrit l'appli, Si elle est conçue pour lire sur stdin et écrire sur stdout après avoir fait quelques trucs entre temps, il faudra multiplexer les ios en utilisant select() ou équivalent. Suivant la manière dont elle est écrite, ça peut être plus ou moins facile.
D'une manière ou d'une autre il faudra sans doute gérer l'asynchronisme quelque part.
C'est difficile de donner *la* bonne solution sans connaître le contexte. Il est généralement préférable de toucher le moins de code existant possible. Si c'est possible, on peut envisager un process intermédiaire qui sert d'adaptateur, l'appli reçoit de lui ce qu'elle attend de stdin et lui envoie sdtdout, le process ne gèrant que le multiplexage en étant l'interlocuteur de toutes les entités accédant ou étant accédée par l'appli. Ca peut être une manière de séparer les problèmes.
Bref, faut voir...
-- http://patrick.davalan.free.fr/
Stan wrote:
Cette application est-elle modifiable ? Si oui, il est possible de
rediriger d'autres descripteurs, ou de la faire écouter sur un
socket.
Oui, j'ai les sources.
Le problème est aussi : est-ce que tu veux les maintenir ?
Si l'application est maintenues, il vaut sans doute mieux voir avec
celui qui maintient afin que les améliorations de part et d'autre
profitent à l'autre.
Modifier d'autres descripteurs ?
autre que stdin/stdout ?
d'un shell on peut rediriger les io, mais je ne suis pas guru du shell
et ça me prend la tête. Si c'est l'appli lancée par inetd qui lance le
script, il y a moyen d'utiliser un pipe.
Par contre l'option des sockets serait plus
compliquée à mettre en oeuvre qu'un échange par fichier.
Ce n'est pas sûr et ça dépend de ce que tu veux, ça dépend de plusieurs
choses :
. de la responsivité souhaitée, si l'appli veut aller voir tous les
jours ou toutes les 10 secondes s'il y a quelque chose pour elle, sans
doute un fichier est meilleur
. Pour plus de responsivité, un handler d'un signal qui lui dit qu'il y
a quelque chose (si c'est le script qui envoie à l'appli) et on va
chercher le fichier là ou il est convenu qu'il soit.
. S'il y a un besoin de responsivité, il est peut-être préférable de
passer par IPC ou par un socket qui permet que le script ne tourne pas
sur la même machine.
*Mais* ça dépend surtout de la manière dont est écrit l'appli, Si elle
est conçue pour lire sur stdin et écrire sur stdout après avoir fait
quelques trucs entre temps, il faudra multiplexer les ios en utilisant
select() ou équivalent. Suivant la manière dont elle est écrite, ça
peut être plus ou moins facile.
D'une manière ou d'une autre il faudra sans doute gérer l'asynchronisme
quelque part.
C'est difficile de donner *la* bonne solution sans connaître le
contexte.
Il est généralement préférable de toucher le moins de code existant
possible. Si c'est possible, on peut envisager un process intermédiaire
qui sert d'adaptateur, l'appli reçoit de lui ce qu'elle attend de stdin
et lui envoie sdtdout, le process ne gèrant que le multiplexage en
étant l'interlocuteur de toutes les entités accédant ou étant accédée
par l'appli. Ca peut être une manière de séparer les problèmes.
Cette application est-elle modifiable ? Si oui, il est possible de rediriger d'autres descripteurs, ou de la faire écouter sur un socket.
Oui, j'ai les sources.
Le problème est aussi : est-ce que tu veux les maintenir ? Si l'application est maintenues, il vaut sans doute mieux voir avec celui qui maintient afin que les améliorations de part et d'autre profitent à l'autre.
Modifier d'autres descripteurs ? autre que stdin/stdout ?
d'un shell on peut rediriger les io, mais je ne suis pas guru du shell et ça me prend la tête. Si c'est l'appli lancée par inetd qui lance le script, il y a moyen d'utiliser un pipe.
Par contre l'option des sockets serait plus compliquée à mettre en oeuvre qu'un échange par fichier.
Ce n'est pas sûr et ça dépend de ce que tu veux, ça dépend de plusieurs choses : . de la responsivité souhaitée, si l'appli veut aller voir tous les jours ou toutes les 10 secondes s'il y a quelque chose pour elle, sans doute un fichier est meilleur . Pour plus de responsivité, un handler d'un signal qui lui dit qu'il y a quelque chose (si c'est le script qui envoie à l'appli) et on va chercher le fichier là ou il est convenu qu'il soit. . S'il y a un besoin de responsivité, il est peut-être préférable de passer par IPC ou par un socket qui permet que le script ne tourne pas sur la même machine. *Mais* ça dépend surtout de la manière dont est écrit l'appli, Si elle est conçue pour lire sur stdin et écrire sur stdout après avoir fait quelques trucs entre temps, il faudra multiplexer les ios en utilisant select() ou équivalent. Suivant la manière dont elle est écrite, ça peut être plus ou moins facile.
D'une manière ou d'une autre il faudra sans doute gérer l'asynchronisme quelque part.
C'est difficile de donner *la* bonne solution sans connaître le contexte. Il est généralement préférable de toucher le moins de code existant possible. Si c'est possible, on peut envisager un process intermédiaire qui sert d'adaptateur, l'appli reçoit de lui ce qu'elle attend de stdin et lui envoie sdtdout, le process ne gèrant que le multiplexage en étant l'interlocuteur de toutes les entités accédant ou étant accédée par l'appli. Ca peut être une manière de séparer les problèmes.
Bref, faut voir...
-- http://patrick.davalan.free.fr/
Nicolas George
"Stan" wrote in message <ei79mn$brr$:
Modifier d'autres descripteurs ? autre que stdin/stdout ?
Quand un processus fils communique avec un processus père au moyen de stdin et stdout, le stdin du fils n'est pas le stdin du père, sinon le père ne pourrait pas écrire dessus. C'est au contraire l'une des extrémités d'une paire de file descriptors obtenus avec pipe(2), qui a été renumérotée avec dup2(2). Idem pour l'autre côté.
"Stan" wrote in message <ei79mn$brr$1@s1.news.oleane.net>:
Modifier d'autres descripteurs ?
autre que stdin/stdout ?
Quand un processus fils communique avec un processus père au moyen de stdin
et stdout, le stdin du fils n'est pas le stdin du père, sinon le père ne
pourrait pas écrire dessus. C'est au contraire l'une des extrémités d'une
paire de file descriptors obtenus avec pipe(2), qui a été renumérotée avec
dup2(2). Idem pour l'autre côté.
Modifier d'autres descripteurs ? autre que stdin/stdout ?
Quand un processus fils communique avec un processus père au moyen de stdin et stdout, le stdin du fils n'est pas le stdin du père, sinon le père ne pourrait pas écrire dessus. C'est au contraire l'une des extrémités d'une paire de file descriptors obtenus avec pipe(2), qui a été renumérotée avec dup2(2). Idem pour l'autre côté.
