Bonjour
Voilà, j'ai un site web, pour lequel je voudrais faire des mises à
jour automatiques de mes statistiques, donc un traitement automatique
avec des scripts PHP lancés à partir de scripts Shell lancés
automatiquement à partir de cron.
C'est possible avec mon hébergeur ( OVH ) et mon hébergement (
240Plan ), mais dans ce cas il n'est possible de lancer un script PHP
qu'en mode CLI, c'est-à-dire avec la ligne de commande suivante:
php mon_script.php
Ce mode CLI fait, que les instructions header de redirections type:
header("Location:deuxieme_script.php"); dans le script lancé
, seront ignorées, et donc je ne sais pas par quoi remplacer ces
instructions.
Ma première question est donc: Qu'est-ce que je met à la place des
instructions header de redirection ?
Ma deuxième question est:
1- Lors du lancement d'un script PHP dans un script Shell, avec une
commande telle que:
php mon_script.php
comment spécifier des paramètres de manière à ce qu'ils soient
interprétables comme des requêtes GET ?
2- Même chose, comment spécifier des paramètres interprétables comme
des requêtes GET, à un script redirigé à partir d'un autre script PHP
lancé de la manière précédente ?
Merci beaucoup beaucoup de vos réponses.
Jean Francois Ortolo
--
Visitez mon Site entièrement gratuit
donnant des Statistiques et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Seulement deux choses: 1- Est-ce que l'instruction require("mon_script.php"); peut être appelée après qu'il y ait eu d'autres instructions PHP avant ?
oui, encore heureux je me demande bien comment on ferait des includes/requires sinon...
2- L'instruction require("mon_script.php?param1=$param1¶m2=$param2"); est-elle valide , c'est-à-dire avec ce type de passage de paramètres, et entre guillemets " " au lieu de entre quotes ' ' , pour lequel les valeurs $param1 et $param2 ne seraient pas substituées ?
on ne risque pas d'aller bien loin avec des parametres de type GET lors d'un require local... c'est un appel de fichier en local ici, pas une requete http
dans votre cas, mon_script.php pourra utiliser $param1 et $param2 de facon totallement transparente
Celà pourrait être une alternative au fait d'affecter des valeurs aux variables d'environnement $_GET['param1'] et $_GET['param2'] avant le require ?
aucun interet si on considere ce que je viens de dire juste avant
Seulement deux choses:
1- Est-ce que l'instruction require("mon_script.php"); peut être
appelée après qu'il y ait eu d'autres instructions PHP avant ?
oui, encore heureux
je me demande bien comment on ferait des includes/requires sinon...
2- L'instruction
require("mon_script.php?param1=$param1¶m2=$param2"); est-elle valide
, c'est-à-dire avec ce type de passage de paramètres, et entre
guillemets " " au lieu de entre quotes ' ' , pour lequel les valeurs
$param1 et $param2 ne seraient pas substituées ?
on ne risque pas d'aller bien loin avec des parametres de type GET lors
d'un require local...
c'est un appel de fichier en local ici, pas une requete http
dans votre cas, mon_script.php pourra utiliser $param1 et $param2 de
facon totallement transparente
Celà pourrait être une alternative au fait d'affecter des valeurs aux
variables d'environnement $_GET['param1'] et $_GET['param2'] avant le
require ?
aucun interet si on considere ce que je viens de dire juste avant
Seulement deux choses: 1- Est-ce que l'instruction require("mon_script.php"); peut être appelée après qu'il y ait eu d'autres instructions PHP avant ?
oui, encore heureux je me demande bien comment on ferait des includes/requires sinon...
2- L'instruction require("mon_script.php?param1=$param1¶m2=$param2"); est-elle valide , c'est-à-dire avec ce type de passage de paramètres, et entre guillemets " " au lieu de entre quotes ' ' , pour lequel les valeurs $param1 et $param2 ne seraient pas substituées ?
on ne risque pas d'aller bien loin avec des parametres de type GET lors d'un require local... c'est un appel de fichier en local ici, pas une requete http
dans votre cas, mon_script.php pourra utiliser $param1 et $param2 de facon totallement transparente
Celà pourrait être une alternative au fait d'affecter des valeurs aux variables d'environnement $_GET['param1'] et $_GET['param2'] avant le require ?
aucun interet si on considere ce que je viens de dire juste avant
Non, jamais. Seule require('http://www........com/mon_script.php?param1=$param1¶m2=$param2" ); est valide
Celà pourrait être une alternative au fait d'affecter des valeurs aux variables d'environnement $_GET['param1'] et $_GET['param2'] avant le require ?
Je reprends afin d'être certain d'avoir bien compris le besoin : vous avez un script maj_stats.php que vous pouvez actuellement appeler dans un navigateur mais pour raisons diverses, vous souhaitez désormais l'appeler en ligne de commande.
Si j'ai compris de travers, merci de repréciser.
Si c'est bien ça, nous sommes d'accords que dans ces scripts actuellement vous récupérez param1 dans $_GET['param1'] (ou $_POST['param1'] ou plus simplement dans $_REQUEST['param1']).
Or, en ligne de commande, les tableaux $_GET, $POST et $_REQUEST ne sont pas renseignés, sauf erreur de ma part (i.e. ça me parait logique, mais je n'ai pas pris le temps de le vérifier par un script de test unitaire).
Donc je vous propose de simuler l'environnement pour vous éviter de modifier le code, c'est à dire de forcer le remplissage de ces tableaux de manière artificielle dans une utilisation en ligne de commande. Exactement comme le souhaitait récemment un autre contributeur pour des scripts de tests unitaires.
Pour ce faire, il suffit d'utiliser un script "wrapper" (to wrap=enrober/empaqueter) qui définit les variables puis inclus maj_stats.php
HTH
JG
Merci beaucoup beaucoup de vos réponses.
Bien à vous.
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Bonsoir,
1- Est-ce que l'instruction require("mon_script.php"); peut être
appelée après qu'il y ait eu d'autres instructions PHP avant ?
Un include/require est strictement la même chose qu'un copié collé du
contenu du fichier passé en paramètre.
Non, jamais. Seule
require('http://www........com/mon_script.php?param1=$param1¶m2=$param2"
); est valide
Celà pourrait être une alternative au fait d'affecter des valeurs aux
variables d'environnement $_GET['param1'] et $_GET['param2'] avant le
require ?
Je reprends afin d'être certain d'avoir bien compris le besoin : vous avez
un script maj_stats.php que vous pouvez actuellement appeler dans un
navigateur mais pour raisons diverses, vous souhaitez désormais l'appeler en
ligne de commande.
Si j'ai compris de travers, merci de repréciser.
Si c'est bien ça, nous sommes d'accords que dans ces scripts actuellement
vous récupérez param1 dans $_GET['param1'] (ou $_POST['param1'] ou plus
simplement dans $_REQUEST['param1']).
Or, en ligne de commande, les tableaux $_GET, $POST et $_REQUEST ne sont pas
renseignés, sauf erreur de ma part (i.e. ça me parait logique, mais je n'ai
pas pris le temps de le vérifier par un script de test unitaire).
Donc je vous propose de simuler l'environnement pour vous éviter de modifier
le code, c'est à dire de forcer le remplissage de ces tableaux de manière
artificielle dans une utilisation en ligne de commande. Exactement comme le
souhaitait récemment un autre contributeur pour des scripts de tests
unitaires.
Pour ce faire, il suffit d'utiliser un script "wrapper" (to
wrap=enrober/empaqueter) qui définit les variables puis inclus maj_stats.php
HTH
JG
Merci beaucoup beaucoup de vos réponses.
Bien à vous.
Jean Francois Ortolo
--
Visitez mon Site entièrement gratuit
donnant des Statistiques et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Non, jamais. Seule require('http://www........com/mon_script.php?param1=$param1¶m2=$param2" ); est valide
Celà pourrait être une alternative au fait d'affecter des valeurs aux variables d'environnement $_GET['param1'] et $_GET['param2'] avant le require ?
Je reprends afin d'être certain d'avoir bien compris le besoin : vous avez un script maj_stats.php que vous pouvez actuellement appeler dans un navigateur mais pour raisons diverses, vous souhaitez désormais l'appeler en ligne de commande.
Si j'ai compris de travers, merci de repréciser.
Si c'est bien ça, nous sommes d'accords que dans ces scripts actuellement vous récupérez param1 dans $_GET['param1'] (ou $_POST['param1'] ou plus simplement dans $_REQUEST['param1']).
Or, en ligne de commande, les tableaux $_GET, $POST et $_REQUEST ne sont pas renseignés, sauf erreur de ma part (i.e. ça me parait logique, mais je n'ai pas pris le temps de le vérifier par un script de test unitaire).
Donc je vous propose de simuler l'environnement pour vous éviter de modifier le code, c'est à dire de forcer le remplissage de ces tableaux de manière artificielle dans une utilisation en ligne de commande. Exactement comme le souhaitait récemment un autre contributeur pour des scripts de tests unitaires.
Pour ce faire, il suffit d'utiliser un script "wrapper" (to wrap=enrober/empaqueter) qui définit les variables puis inclus maj_stats.php
HTH
JG
Merci beaucoup beaucoup de vos réponses.
Bien à vous.
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
John Gallet
Bonsoir,
Mon problème est résolu avec la commande suivante: /usr/bin/wget -r -l 0 -Q 0 -T 0 --delete-after mon_script.php?param1=$param1¶m2=$param2 Les paramètres à ce wget, sont respectivement pour permettre les accès récursifs sans limite, et sans limite de temps de chargement.
Quand je vous disais que c'est en général plus simple ;-) En revanche, je ne savais pas si wget acceptait les redirections http de type meta http-equiv ou header location.
Cà marche très bien, l'ensemble de mes statistiques ce soir a été mis à jour en un tout petit peu plus de 30 secondes, résultat parfait sans aucune modification de mes scripts PHP. Problème résolu.
Parfait ! C'est à boire à boire à boireeeeeuuuuu....
Il ne me reste plus qu'à générer au lieu d'une page HTML, un script PHP gérant la variable $_SERVER['HTTP_REFERER'] pour authentification.
Je n'en vois vraiment pas l'intérêt. Justement puisque vous êtes dans l'utilisation de wget, vous aurez peut-être remarqué l'option --headers, qui permet de déclarer ce que vous voulez comme http_referrer... Et de mémoire il supporte mêmz l'option --referrer à partir d'une certaine version... Donc sauf à volontairement le passer en wget à une valeur délirante (impossible à deviner, en gros on réinvente le mot de passe...)vérifiée dans le script, ça n'apporte aucune sécurité.
a++ JG
Bonsoir,
Mon problème est résolu avec la commande suivante:
/usr/bin/wget -r -l 0 -Q 0 -T 0 --delete-after
mon_script.php?param1=$param1¶m2=$param2
Les paramètres à ce wget, sont respectivement pour permettre les
accès récursifs sans limite, et sans limite de temps de chargement.
Quand je vous disais que c'est en général plus simple ;-)
En revanche, je ne savais pas si wget acceptait les redirections http de
type meta http-equiv ou header location.
Cà marche très bien, l'ensemble de mes statistiques ce soir a été mis
à jour en un tout petit peu plus de 30 secondes, résultat parfait sans
aucune modification de mes scripts PHP.
Problème résolu.
Parfait ! C'est à boire à boire à boireeeeeuuuuu....
Il ne me reste plus qu'à générer au lieu d'une page HTML, un script
PHP gérant la variable $_SERVER['HTTP_REFERER'] pour authentification.
Je n'en vois vraiment pas l'intérêt. Justement puisque vous êtes dans
l'utilisation de wget, vous aurez peut-être remarqué l'option --headers, qui
permet de déclarer ce que vous voulez comme http_referrer... Et de mémoire
il supporte mêmz l'option --referrer à partir d'une certaine version... Donc
sauf à volontairement le passer en wget à une valeur délirante (impossible à
deviner, en gros on réinvente le mot de passe...)vérifiée dans le script, ça
n'apporte aucune sécurité.
Mon problème est résolu avec la commande suivante: /usr/bin/wget -r -l 0 -Q 0 -T 0 --delete-after mon_script.php?param1=$param1¶m2=$param2 Les paramètres à ce wget, sont respectivement pour permettre les accès récursifs sans limite, et sans limite de temps de chargement.
Quand je vous disais que c'est en général plus simple ;-) En revanche, je ne savais pas si wget acceptait les redirections http de type meta http-equiv ou header location.
Cà marche très bien, l'ensemble de mes statistiques ce soir a été mis à jour en un tout petit peu plus de 30 secondes, résultat parfait sans aucune modification de mes scripts PHP. Problème résolu.
Parfait ! C'est à boire à boire à boireeeeeuuuuu....
Il ne me reste plus qu'à générer au lieu d'une page HTML, un script PHP gérant la variable $_SERVER['HTTP_REFERER'] pour authentification.
Je n'en vois vraiment pas l'intérêt. Justement puisque vous êtes dans l'utilisation de wget, vous aurez peut-être remarqué l'option --headers, qui permet de déclarer ce que vous voulez comme http_referrer... Et de mémoire il supporte mêmz l'option --referrer à partir d'une certaine version... Donc sauf à volontairement le passer en wget à une valeur délirante (impossible à deviner, en gros on réinvente le mot de passe...)vérifiée dans le script, ça n'apporte aucune sécurité.
a++ JG
loufoque
Pozzo a dit le 09/07/2004 01:06:
Je ne suis pas sûr que PHP soit le langage le plus adapté dans ce contexte... voyez plutot Perl à mon avis
C'est un troll ? PHP n'est pas qu'un langage pour le web, c'est aussi un langage de script complet.
Pozzo a dit le 09/07/2004 01:06:
Je ne suis pas sûr que PHP soit le langage le plus adapté dans ce
contexte... voyez plutot Perl à mon avis
C'est un troll ?
PHP n'est pas qu'un langage pour le web, c'est aussi un langage de
script complet.
Je ne suis pas sûr que PHP soit le langage le plus adapté dans ce contexte... voyez plutot Perl à mon avis
C'est un troll ? PHP n'est pas qu'un langage pour le web, c'est aussi un langage de script complet.
Jean Francois Ortolo
John Gallet wrote:
Bonsoir,
Mon problème est résolu avec la commande suivante: /usr/bin/wget -r -l 0 -Q 0 -T 0 --delete-after mon_script.php?param1=$param1¶m2=$param2 Les paramètres à ce wget, sont respectivement pour permettre les accès récursifs sans limite, et sans limite de temps de chargement.
Quand je vous disais que c'est en général plus simple ;-) En revanche, je ne savais pas si wget acceptait les redirections http de type meta http-equiv ou header location.
Ben apparemment... Le seul problème nécéssaire, est que wget doit accepter les redirections, donc les appels récursifs.
Le paramètre: -r -l 0 sert respectivement à ce que wget accepte l'es appels récursifs ( -r ), et qu'il n'y ait pas de timeout de chargement ( -l 0 ).
Les -Q 0 et -T 0 je ne sais plus, mais ça fonctionne sur mon ordi chez moi en local.
Le --delete-after ,c'est pour effacer les fichiers de trace qui sont laissés à cause du fait que les appels récursifs sont permis. C'est du moins ce que j'ai compris de la commande 'man wget' que j'ai sur mon système Linux RedHat9.
Cà marche très bien, l'ensemble de mes statistiques ce soir a été mis à jour en un tout petit peu plus de 30 secondes, résultat parfait sans aucune modification de mes scripts PHP. Problème résolu.
Oui mais... Seulement en local chez moi pour l'instant.
En remote, mes scripts sont bien déclenchés par cron ( j'ai vérifié ), mais apparemment la commande wget n'est pas lancée... Probablement un problème de path. Théoriquement le path de wget est: /usr/bin/wget ( sur mon ordi ), mais sur le serveur OVH, le path du programme php est: /usr/local/bin/php , donc celà se pourrait que le path de wget soit /usr/local/bin/wget
Je suis en train de me renseigner à ce sujet par email auprès de leur hotline. Problèmes de communication. :)
Merci beaucoup à vous pour votre aide, et si vous pouviez regarder de nouveau le thread plus haut sur l'authentification des appels à un script PHP, j'ai répondu à votre réponse avec des questions, merci beaucoup beaucoup si vous pouviez me donner des réponses.
Bien à vous.
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
John Gallet wrote:
Bonsoir,
Mon problème est résolu avec la commande suivante:
/usr/bin/wget -r -l 0 -Q 0 -T 0 --delete-after
mon_script.php?param1=$param1¶m2=$param2
Les paramètres à ce wget, sont respectivement pour permettre les
accès récursifs sans limite, et sans limite de temps de chargement.
Quand je vous disais que c'est en général plus simple ;-)
En revanche, je ne savais pas si wget acceptait les redirections http de
type meta http-equiv ou header location.
Ben apparemment...
Le seul problème nécéssaire, est que wget doit accepter les
redirections, donc les appels récursifs.
Le paramètre: -r -l 0 sert respectivement à ce que wget accepte l'es
appels récursifs ( -r ), et qu'il n'y ait pas de timeout de chargement (
-l 0 ).
Les -Q 0 et -T 0 je ne sais plus, mais ça fonctionne sur mon ordi
chez moi en local.
Le --delete-after ,c'est pour effacer les fichiers de trace qui sont
laissés à cause du fait que les appels récursifs sont permis. C'est du
moins ce que j'ai compris de la commande 'man wget' que j'ai sur mon
système Linux RedHat9.
Cà marche très bien, l'ensemble de mes statistiques ce soir a été mis
à jour en un tout petit peu plus de 30 secondes, résultat parfait sans
aucune modification de mes scripts PHP.
Problème résolu.
Oui mais...
Seulement en local chez moi pour l'instant.
En remote, mes scripts sont bien déclenchés par cron ( j'ai vérifié
), mais apparemment la commande wget n'est pas lancée... Probablement un
problème de path. Théoriquement le path de wget est: /usr/bin/wget ( sur
mon ordi ), mais sur le serveur OVH, le path du programme php est:
/usr/local/bin/php , donc celà se pourrait que le path de wget soit
/usr/local/bin/wget
Je suis en train de me renseigner à ce sujet par email auprès de leur
hotline. Problèmes de communication. :)
Merci beaucoup à vous pour votre aide, et si vous pouviez regarder de
nouveau le thread plus haut sur l'authentification des appels à un
script PHP, j'ai répondu à votre réponse avec des questions, merci
beaucoup beaucoup si vous pouviez me donner des réponses.
Bien à vous.
Jean Francois Ortolo
--
Visitez mon Site entièrement gratuit
donnant des Statistiques et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Mon problème est résolu avec la commande suivante: /usr/bin/wget -r -l 0 -Q 0 -T 0 --delete-after mon_script.php?param1=$param1¶m2=$param2 Les paramètres à ce wget, sont respectivement pour permettre les accès récursifs sans limite, et sans limite de temps de chargement.
Quand je vous disais que c'est en général plus simple ;-) En revanche, je ne savais pas si wget acceptait les redirections http de type meta http-equiv ou header location.
Ben apparemment... Le seul problème nécéssaire, est que wget doit accepter les redirections, donc les appels récursifs.
Le paramètre: -r -l 0 sert respectivement à ce que wget accepte l'es appels récursifs ( -r ), et qu'il n'y ait pas de timeout de chargement ( -l 0 ).
Les -Q 0 et -T 0 je ne sais plus, mais ça fonctionne sur mon ordi chez moi en local.
Le --delete-after ,c'est pour effacer les fichiers de trace qui sont laissés à cause du fait que les appels récursifs sont permis. C'est du moins ce que j'ai compris de la commande 'man wget' que j'ai sur mon système Linux RedHat9.
Cà marche très bien, l'ensemble de mes statistiques ce soir a été mis à jour en un tout petit peu plus de 30 secondes, résultat parfait sans aucune modification de mes scripts PHP. Problème résolu.
Oui mais... Seulement en local chez moi pour l'instant.
En remote, mes scripts sont bien déclenchés par cron ( j'ai vérifié ), mais apparemment la commande wget n'est pas lancée... Probablement un problème de path. Théoriquement le path de wget est: /usr/bin/wget ( sur mon ordi ), mais sur le serveur OVH, le path du programme php est: /usr/local/bin/php , donc celà se pourrait que le path de wget soit /usr/local/bin/wget
Je suis en train de me renseigner à ce sujet par email auprès de leur hotline. Problèmes de communication. :)
Merci beaucoup à vous pour votre aide, et si vous pouviez regarder de nouveau le thread plus haut sur l'authentification des appels à un script PHP, j'ai répondu à votre réponse avec des questions, merci beaucoup beaucoup si vous pouviez me donner des réponses.
Bien à vous.
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Jean Francois Ortolo
Finalement... Je n'arrive pas à déclencher la commande wget à partir d'un script Shell Bash déclenché par cron sur le serveur d'OVH.
Je sais que la commande /usr/local/bin/php est entièrement disponible et fonctionne à partir d'un script Shell Bash, c'est indiqué formellement dans la "FAQ par Mail" d'OVH.
Je vais donc faire tous les changements nécéssaires et suffisant pour lancer mes scripts en mode CLI, y compris faire les quelques wrappers nécéssaire, et mettre à jour les varaiables $_GET[' '] à l'intérieur de chaque script avant chaque include.
Il n'y aura pas besoin de donner le chemin complet ( avec http://www.ortolojf-courses.com/ ), car chaque script PHP appelé héritera de l'environnement _GET de l'appelant, il n'y aura pas besoin de spécifier de paramètres aux scripts appelés.
D'autre part, à partir de PHP4 les scripts appelés par des include, ne sont inclus effectivement que si l'exécution du programme l'exige. Je peux donc inclure dans un script ce même script ( imbrication donc ), puisque l'include ne sera interprété que si l'exécution l'exige.
Là j'ai besoin de savoir si une inclusioon effective dépend uniquement de l'exécution effective, ou si la condition d'inclusion ou non, doit pouvoir être évaluée en statique, avant toute exécution du script. ( Après tout il y abien un compilateur "just in time" dans PHP4, non ?
Merci beaucoup de votre réponse à cette question.
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Finalement...
Je n'arrive pas à déclencher la commande wget à partir d'un script
Shell Bash déclenché par cron sur le serveur d'OVH.
Je sais que la commande /usr/local/bin/php est entièrement disponible
et fonctionne à partir d'un script Shell Bash, c'est indiqué
formellement dans la "FAQ par Mail" d'OVH.
Je vais donc faire tous les changements nécéssaires et suffisant pour
lancer mes scripts en mode CLI, y compris faire les quelques wrappers
nécéssaire, et mettre à jour les varaiables $_GET[' '] à l'intérieur de
chaque script avant chaque include.
Il n'y aura pas besoin de donner le chemin complet ( avec
http://www.ortolojf-courses.com/ ), car chaque script PHP appelé
héritera de l'environnement _GET de l'appelant, il n'y aura pas besoin
de spécifier de paramètres aux scripts appelés.
D'autre part, à partir de PHP4 les scripts appelés par des include,
ne sont inclus effectivement que si l'exécution du programme l'exige. Je
peux donc inclure dans un script ce même script ( imbrication donc ),
puisque l'include ne sera interprété que si l'exécution l'exige.
Là j'ai besoin de savoir si une inclusioon effective dépend
uniquement de l'exécution effective, ou si la condition d'inclusion ou
non, doit pouvoir être évaluée en statique, avant toute exécution du
script. ( Après tout il y abien un compilateur "just in time" dans
PHP4, non ?
Merci beaucoup de votre réponse à cette question.
Jean Francois Ortolo
--
Visitez mon Site entièrement gratuit
donnant des Statistiques et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Finalement... Je n'arrive pas à déclencher la commande wget à partir d'un script Shell Bash déclenché par cron sur le serveur d'OVH.
Je sais que la commande /usr/local/bin/php est entièrement disponible et fonctionne à partir d'un script Shell Bash, c'est indiqué formellement dans la "FAQ par Mail" d'OVH.
Je vais donc faire tous les changements nécéssaires et suffisant pour lancer mes scripts en mode CLI, y compris faire les quelques wrappers nécéssaire, et mettre à jour les varaiables $_GET[' '] à l'intérieur de chaque script avant chaque include.
Il n'y aura pas besoin de donner le chemin complet ( avec http://www.ortolojf-courses.com/ ), car chaque script PHP appelé héritera de l'environnement _GET de l'appelant, il n'y aura pas besoin de spécifier de paramètres aux scripts appelés.
D'autre part, à partir de PHP4 les scripts appelés par des include, ne sont inclus effectivement que si l'exécution du programme l'exige. Je peux donc inclure dans un script ce même script ( imbrication donc ), puisque l'include ne sera interprété que si l'exécution l'exige.
Là j'ai besoin de savoir si une inclusioon effective dépend uniquement de l'exécution effective, ou si la condition d'inclusion ou non, doit pouvoir être évaluée en statique, avant toute exécution du script. ( Après tout il y abien un compilateur "just in time" dans PHP4, non ?
Merci beaucoup de votre réponse à cette question.
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Jean Francois Ortolo
Jean Francois Ortolo wrote:
Seulement en local chez moi pour l'instant.
En remote, mes scripts sont bien déclenchés par cron ( j'ai vérifié ), mais apparemment la commande wget n'est pas lancée... Probablement un problème de path. Théoriquement le path de wget est: /usr/bin/wget ( sur mon ordi ), mais sur le serveur OVH, le path du programme php est: /usr/local/bin/php , donc celà se pourrait que le path de wget soit /usr/local/bin/wget
Bonjour J'ai bien vérifié le PATH de wget sur le serveur d'OVH en redirectionnant la commande `which wget` sur un fichier err4.txt que j'ai chargé par FTP, le chemin est bien: /usr/bin/wget
Maintenant, au lieu de redirectionner la sortie erreur de l'appel à wget ( 2 ) sur /dev/null, je la redirige sur des fichiers erreurs de log, on va voir ce que celà va donner...
Théoriquement, wget est accessible et donc disponible, il n'y a plus qu'à analyser son comportement d'après ses messages d'erreur.
Ouf, ceci va m'épargner de passer en mode CLI.
Hé bé, non seulement je suis casanier, mais en plus je suis paresseux et la loi du moindre effort... :)
Merci beaucoup beaucoup pour tous vos conseils.
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Jean Francois Ortolo wrote:
Seulement en local chez moi pour l'instant.
En remote, mes scripts sont bien déclenchés par cron ( j'ai vérifié ),
mais apparemment la commande wget n'est pas lancée... Probablement un
problème de path. Théoriquement le path de wget est: /usr/bin/wget ( sur
mon ordi ), mais sur le serveur OVH, le path du programme php est:
/usr/local/bin/php , donc celà se pourrait que le path de wget soit
/usr/local/bin/wget
Bonjour
J'ai bien vérifié le PATH de wget sur le serveur d'OVH en
redirectionnant la commande `which wget` sur un fichier err4.txt que
j'ai chargé par FTP, le chemin est bien: /usr/bin/wget
Maintenant, au lieu de redirectionner la sortie erreur de l'appel à
wget ( 2 ) sur /dev/null, je la redirige sur des fichiers erreurs de
log, on va voir ce que celà va donner...
Théoriquement, wget est accessible et donc disponible, il n'y a plus
qu'à analyser son comportement d'après ses messages d'erreur.
Ouf, ceci va m'épargner de passer en mode CLI.
Hé bé, non seulement je suis casanier, mais en plus je suis paresseux
et la loi du moindre effort... :)
Merci beaucoup beaucoup pour tous vos conseils.
Jean Francois Ortolo
--
Visitez mon Site entièrement gratuit
donnant des Statistiques et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.ortolojf-courses.com
En remote, mes scripts sont bien déclenchés par cron ( j'ai vérifié ), mais apparemment la commande wget n'est pas lancée... Probablement un problème de path. Théoriquement le path de wget est: /usr/bin/wget ( sur mon ordi ), mais sur le serveur OVH, le path du programme php est: /usr/local/bin/php , donc celà se pourrait que le path de wget soit /usr/local/bin/wget
Bonjour J'ai bien vérifié le PATH de wget sur le serveur d'OVH en redirectionnant la commande `which wget` sur un fichier err4.txt que j'ai chargé par FTP, le chemin est bien: /usr/bin/wget
Maintenant, au lieu de redirectionner la sortie erreur de l'appel à wget ( 2 ) sur /dev/null, je la redirige sur des fichiers erreurs de log, on va voir ce que celà va donner...
Théoriquement, wget est accessible et donc disponible, il n'y a plus qu'à analyser son comportement d'après ses messages d'erreur.
Ouf, ceci va m'épargner de passer en mode CLI.
Hé bé, non seulement je suis casanier, mais en plus je suis paresseux et la loi du moindre effort... :)
Merci beaucoup beaucoup pour tous vos conseils.
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Luc
Hé bé, non seulement je suis casanier, mais en plus je suis paresseux et la loi du moindre effort... :)
pas au point d'utiliser "rediriger" à la place de l'étonnant "redirectionner" !
Hé bé, non seulement je suis casanier, mais en plus je suis paresseux
et la loi du moindre effort... :)
pas au point d'utiliser "rediriger" à la place de l'étonnant
"redirectionner" !
Hé bé, non seulement je suis casanier, mais en plus je suis paresseux et la loi du moindre effort... :)
pas au point d'utiliser "rediriger" à la place de l'étonnant "redirectionner" !
Jean Francois Ortolo
Bé Je crois que j'ai trouvé d'où venait l'erreur.
Dans le script Shell Bash appelant /usr/bin/wget, il suffisait d'antislasher les ampersand ( & au lieu de & ), car le shell le prenait comme un device driver, et interprétait ce qui venait après comme une commande supplémentaire.
Vais voir si ça marche demain.
Bougre de Shell...
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Bé
Je crois que j'ai trouvé d'où venait l'erreur.
Dans le script Shell Bash appelant /usr/bin/wget, il suffisait
d'antislasher les ampersand ( & au lieu de & ), car le shell le prenait
comme un device driver, et interprétait ce qui venait après comme une
commande supplémentaire.
Vais voir si ça marche demain.
Bougre de Shell...
Jean Francois Ortolo
--
Visitez mon Site entièrement gratuit
donnant des Statistiques et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Dans le script Shell Bash appelant /usr/bin/wget, il suffisait d'antislasher les ampersand ( & au lieu de & ), car le shell le prenait comme un device driver, et interprétait ce qui venait après comme une commande supplémentaire.
Vais voir si ça marche demain.
Bougre de Shell...
Jean Francois Ortolo
-- Visitez mon Site entièrement gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
