Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage Perl appel d'un cgi a partir d'un cgi avec la commande system()

appel d'un cgi a partir d'un cgi avec la commande system()

3 réponses
Avatar
Edwin Vancleef
system( "./prog.cgi param1=12 param2=13" );

Si l'exécution se fait à partir d'un navigateur, prog.cgi ne trouvera aucun
paramètre. Pourtant, si on exécute la commande dans le shell, les paramètres
seront bien reçus. Pourquoi ?

Lorsque l'exécution se fait à partir d'un navigateur, des variables
d'environnement sont définies, indiquant à prog.cgi que l'exécution se fait à
partir d'un navigateur. prog.cgi va donc chercher ses paramètres dans ces
variables d'environnement, et non dans @ARGV.

Une solution est d'effacer la variable d'environnement "REQUEST_METHOD" :

delete $ENV{"REQUEST_METHOD"};
system( "./prog.cgi param1=12 param2=13" );

Ainsi, prog.cgi pensera que l'appel ne se fait pas à partir d'un navigateur, et
lira ses paramètres dans @ARGV.

Une autre solution est de redéfinir la liste des paramètres dans la variable
"QUERY_STRING" :

$ENV{"QUERY_STRING"} = "param1=12&param2=13";
system( "./prog.cgi" );

---

J'ai cherché ces 2 solutions sur le Net, mais je n'ai rien trouvé. Je me
demande si elles ne sont pas trop marginales, et s'il n'y aurait pas une
solution plus courante...
Signaler un problème avec ce contenu

3 réponses

Supprimer
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
Avatar
Paul Gaborit
À (at) 26 Oct 2006 12:40:50 GMT,
Edwin Vancleef écrivait (wrote):
J'ai cherché ces 2 solutions sur le Net, mais je n'ai rien trouvé. Je me
demande si elles ne sont pas trop marginales, et s'il n'y aurait pas une
solution plus courante...


En général, ce boulot de redirection se fait soit directement par le
navigateur (le premier CGI redirige le navigateur vers le second CGI)
mais ça ne peut pas marcher avec des données POSTées (redirection
interdite dans ce cas), soit en utilisant une redirection interne du
serveur.

Votre solution (la seconde variante me paraît plus propre car elle ne
repose pas sur le fait que le deuxième cgi utilise le module CGI de
Perl) pourrait être améliorée en remplaçant l'appel à system() par un
appel à exec() puisque le premier cgi ne doit plus rien faire
après. Dans tous les cas, ça ne marchera pas dans un environnement
intégré (comme mod_perl).

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>

Avatar
Régine
Avec ça peut-être...

use LWP::Simple;
getprint("http://votre.serveur/cgi-bin/nouveau_script.pl?$ParametresDivers" );

Cordialement
G. Besomi



system( "./prog.cgi param1 param2" );

Si l'exécution se fait à partir d'un navigateur, prog.cgi ne trouvera aucun
paramètre. Pourtant, si on exécute la commande dans le shell, les par amètres
seront bien reçus. Pourquoi ?

Lorsque l'exécution se fait à partir d'un navigateur, des variables
d'environnement sont définies, indiquant à prog.cgi que l'exécution se fait à
partir d'un navigateur. prog.cgi va donc chercher ses paramètres dans c es
variables d'environnement, et non dans @ARGV.

Une solution est d'effacer la variable d'environnement "REQUEST_METHOD" :

delete $ENV{"REQUEST_METHOD"};
system( "./prog.cgi param1 param2" );

Ainsi, prog.cgi pensera que l'appel ne se fait pas à partir d'un naviga teur, et
lira ses paramètres dans @ARGV.

Une autre solution est de redéfinir la liste des paramètres dans la v ariable
"QUERY_STRING" :

$ENV{"QUERY_STRING"} = "param1&param2";
system( "./prog.cgi" );

---

J'ai cherché ces 2 solutions sur le Net, mais je n'ai rien trouvé. Je me
demande si elles ne sont pas trop marginales, et s'il n'y aurait pas une
solution plus courante...


Avatar
Edwin Vancleef
Avec ça peut-être...

use LWP::Simple;
getprint("http://votre.serveur/cgi-bin/nouveau_script.pl?$ParametresDivers");


Cette solution peut ne pas convenir dans le cas où on ne voudrait pas que le
nouveau_script.pl soit à disposition d'une requête HTTP.