Comment lancer un script php à parrtir d'un autre script php ?

[ortolojf]

Bonsoir

Théoriquement, avec un tel script lancer.php :

<?php
$script = "/usr/bin/php -q -f ./stats.php ";

$output = @shell_exec($script . $date_debut . " " . $date_fin . " 2>/dev/null");

echo $output . "<br />\n";

exit;
?>

, j'arriverai à lancer à partir de ce script lancer.php déclenché par un navigateur, le script stats.php situé dans le même répertoire que lancer.php , avec les deux paramètres $date_debut et $date_fin , avec redirection des erreurs dans le puids sans fond /dev/null de Linux.

La variable $output contiendra au retour, ce qui a aura été affiché par stats.php, et le script stats.php pourra récupérer les deux paramètres $date_debut et $date_fin dans les variables $argv[1] et $argv[2] , où $argv = $_SERVER['argv'];

Ma question :

Voyez-vous un problème quelconque ( garbage ou autre dans $output ), si l'interpréteur /usr/bin/php a été compilé en mode cgi, et non pas cli ?

Faut-il dans ce cas, rajouter quelque chose aux paramètres -q et -f de /usr/bin/php ?

Par exemple le paramètre -n, qui annulerait l'influence du fichier de configuration php.ini de php ?

Je sais que php existe toujours dans /usr/bin/, mais je ne peux pas prévoir à priori, s'il a été compilé en mode cgi, ou cli...

Merci beaucoup de vos réponses.

Bien à vous.

Amicalement.

Jean-François Ortolo

[pprem]

si le script en question peut être utilisé en direct, tu peux aussi utiliser la fonction EVAL ou un simple INCLUDE ou REQUIRE

si le script est accessible depuis un serveur web, tu peux (selon l'hébergeur) passer par un file_get_contents(), file(), fopen(), ou curl

tout dépend des circonstances, de l'utilisation et de la configuration de la machine sur laquelle tu es

[ortolojf]

si le script en question peut être utilisé en direct, tu peux aussi utiliser la fonction EVAL ou un simple INCLUDE ou REQUIRE

si le script est accessible depuis un serveur web, tu peux (selon l'hébergeur) passer par un file_get_contents(), file(), fopen(), ou curl

tout dépend des circonstances, de l'utilisation et de la configuration de la machine sur laquelle tu es

Bonjour Monsieur

Je préfère écarter toute solution qui m'obligerait à faire une requête http depuis le script lanceur.

Ma seule question résiduelle, à part le problème du paramètre -n, serait de savoir si dans un script php lanceur, plusieurs instructions shell_exec() de ce type peuvent se suivre correctement.

Je sais que mon serveur cible ( hébergement mutualisé Sivit/Nerim ), accepte les fonctions shell_exec(), j'ai déjà testé.

Mais je m'interroge sur la possibilité de lancer plusieurs shell_exec() ( un certain nombre en fait ) au cours de l'exécution du script lanceur, même si chaque shell_exec() sera terminé avant que le script lanceur ne continue son exécution.

J'ai vu dans les commentaires du PHP Manual sur cette fonction shell_exec(), qu'une fonction exec() ( c'est une fonction différente de shell_exec() ), directement suivie par une fonction shell_exec(), faisait que la fonction shell_exec() pouvait ne pas fonctionner.

Cependant, dans ces commentaires, le cas que j'évoque n'est pas indiqué.

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo

[pprem]

ok, dans ce cas la réponse est "oui" puisque l'hébergeur accepte le shell_exec

[creadiff]

Ayant déjà testé de nombreuses fonctions PHP pour le multi-threading, je ne peux que conseiller proc_open() : meilleure souplesse, possibilité de récupérer des informations sur le processus en cours d''exécution...

http://php.net/manual/fr/function.proc-open.php

[ortolojf]

ok, dans ce cas la réponse est "oui" puisque l'hébergeur accepte le shell_exec

Merci beaucoup Monsieur

Mais... Si l'interpréteur /usr/bin/php a été compilé en mode cgi, ne faut-il pas, pour que $output ne contienne pas de "garbage", mettre aussi le paramètre -n en plus de -q et -f, devant /usr/bin/php dans la fonction shell_exec() ?

J'ai bien lu la réponse de creadiff , mais ces fonctions proc_open(), popen() et ou fopen(), ne me paraissent pas convenir ( trop compliquées ou faisant intervenir une requête http ).

La fonction shell_exec() fonctionne directement du serveur vers le serveur, c'est beaucoup plus rapide qu'une requête http.

Quant aux autres : proc_open() et popen() , j'ai vu le PHP Manual, et j'ai de la difficulté à me rendre compte comment c'est utilisable, avec un script php ayant des paramètres.

Je pense m'en tenir à la fonction shell_exec(), mais j'ai besoin de savoir si le paramètre -n permet de faire en sorte, que la variable $output soit correctement alimentée, même si /usr/bin/php a été compilé comme cgi.

D'autre part, il me semblait que dasn certains cas, il fallait faire précéder la commende "/usr/bin/php" dans shell_exec(), par la commende : "env -i;" , pour effacer les variables d'environnement juste avant de lancer /usr/bin/php et le script php à lancer.

Celà est-il la bonne solution dans le cas où php est compilé comme cgi ?

Il me semble me rappeler, que c'est la solution que j'ai utilisée il y a quelques années pour mon site partenaire, dont l'interpréteur php était compilé comme cgi, mais je ne suis pas sûr. ;(

Merci beaucoup de votre réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo

[pprem]

il y a juste un truc : /usr/bin/php n'est pas du CGI, c'est la version CLI de PHP, donc pas d'interférence avec Apache et sa config

[ortolojf]

il y a juste un truc : /usr/bin/php n'est pas du CGI, c'est la version CLI de PHP, donc pas d'interférence avec Apache et sa config

Bonjour pprem

Je sais bien qu'à l'époque, le programme /usr/bin/php du serveur de mon site partenaire, était compilé en mode cgi.

J'ai donc toujours, le besoin d'avoir les réponses à ces deux questions :

- Faut-il, dans ce cas, mettre aussi le paramètre -n en plus de -q et -f en face de /usr/bin/php dans la fonction shell_exec() ? ( Le paramètre -n fait que le fichier de configuration php.ini n'est pas pris en compte au moment de l'exécution de php ).

- Est-ce que le fait de mettre "env -i;" avant "/usr/bin/php" dans shell_exec() ( la commande Shell env -i efface les variables d'environnement ), pourra assurer aussi, que la variable $output recevant le résultat de la fonction shell_exec() ( ce qui est affiché par le script php lancé par /usr/bin/php ), cette variable $output, sera propre, est ne contiendra pas de caractères parasites ( = garbage ) ?

Merci beaucoup beaucoup de vos réponses.

Bien à vous.

Amicalement.

Jean-François Ortolo

[pprem]

et pourquoi ne pas faire le test en direct sur le serveur ou demander directement à l'hébergeur ? après tout si la config n'est pas standard, il n'y a qu'en essayant que la réponse apparaîtra

[ortolojf]

et pourquoi ne pas faire le test en direct sur le serveur ou demander directement à l'hébergeur ? après tout si la config n'est pas standard, il n'y a qu'en essayant que la réponse apparaîtra

Bonsoir pprem

Bon, ben je vois que tu n'as pa la réponse à ma question... ;(

Effectivement si j'essaye avec et sans -n et avec et sans "/bin/env -i;" ( la commande env est toujours dans le répertoire /bin/ ), j'aurai une idée sans certtitude, si /usr/bin/php est cgi ou cli.

Et... Si j'obtiens un bon résultat avec ces deux modifications, j'aurai fait tout ce que j'ai pu.

Je peux toujours demander à mon hébergeur ( Sivit/Nerim ), si /usr/bin/php est en mode cgi ou cli... Mais qu'est-ce qui me garantira, que la solution est pérenne, avec l'évolution de l'hébergement ?

La seule solution que j'ai, est de tester avec mon site partenaire, en choisissant le répertoire de php tel que php soit en mode cgi, et de tester avec ou sans ces modifications.

Je crois effectivement, que le système d'exploitation de mon site partenaire - serveur dédié - , est gentoo.

Je pense, qu'il y a deux interpréteurs php dans deux répertoires différents, l'un, cgi l'autre, cli.

Je vais voir...

Merci beaucoup de ta réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo

[ortolojf]

Bonsoir pprem

Voilà, j'ai regardé sur le serveur de mon site partenaire.

Les deux interpréteurs php ( respectivement cli et cgi ) de mon site partenaire, sont :

/usr/bin/php , et
/usr/bin/php-cgi

Ce sont tous les deux ( php et php-cgi ) des liens symboliques vers les véritables exécutables, qui sont situés dans le répertoire : /usr/lib64/php5/bin/

C'est une distribution gentoo.

Je vais tester les deux modifications dont je parlais, avec /usr/bin/php-cgi , pour voir si ces modifications sont efficaces avec un php compilé en mode cgi.

Après, je remettrai /usr/bin/php pour le script réel destiné à mon site.

Je pense, que le problème est virtuellement résolu.

Bien à vous.

Amicalement.

Jean-François Ortolo