Discussion :

[laclac]

Bonjour,

Je m'excuse si ma demande n'est pas à la bonne place ; je n'ai pas trouvé de section dédiée aux CRON dans l'interface de l'hébergeur web. Mon problème semble assez courant, mais je n'ai pas encore trouvé de solution.

J'ai configuré un CRON sur mon hébergeur PHP mutualisé via l'interface CPanel. La commande que je suis censé utiliser pour appeler ma page `monscript.php` est la suivante (selon les exemples de scripts fournis par l'hébergeur) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/usr/bin/php80 -f /home/sites/11/82103d299/monsite/monscript.php

La page est bien appelée ! Cool !
Note: Mon site est situé à "/home/sites/11/82103d299/" et les répertoires avant cela sont complètement inaccessibles pour moi.

Cependant, la mauvaise nouvelle est que j'ai une commande dans `monscript.php` qui ne se déroule pas comme prévu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$lines = file('toto.txt', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);

Lorsque j'appelle directement la page, tout fonctionne très bien en prod et sur mon environnement de développement, mais cela ne marche pas du tout lorsque le CRON l'appelle ! Je pense que c'est parce que lorsque je lance le script directement, il cherche le fichier au même niveau que lui (je pourrais le remplacer par `./toto.txt`, cela ne change rien).

Cependant, lorsque le CRON l'appelle, cela ne fonctionne pas car la commande `file('toto.txt')` semble chercher au niveau du CRON lui-même, c'est-à-dire sur "/usr/bin/", et donc il ne le trouve pas.

Afin de résoudre ce problème, je suis obligé d'écrire l'URL absolue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$lines = file('/home/sites/11/82103d299/toto.txt', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);

Cependant, ce code n'est clairement pas idéal, car il ne fonctionne plus sur mon environnement de développement et n'est pas du tout portable en cas de changement d'hébergeur ou même de répertoire.

Je désespère de trouver une commande CRON qui me permette de me positionner au niveau du script, de sorte que les appels à des chemins relatifs fonctionnent.
Si vous avez une solution, je suis preneur !

Merci d'avance !

Remarque : Actuellement, le problème est si critique qu'en solution de contournement, j'ai créé un CRON qui appelle une page nommée 'moncron.php' ayant pour seul but d'appeler `monscript.php` en utilisant cURL. Ainsi, avec cURL, les chemins relatifs fonctionnent, et mon fichier `./toto.txt` est correctement lu.

[Sve@r]

Bonjour

je n'ai pas trouvé de section dédiée aux CRON dans l'interface de l'hébergeur web.

Un peu normal. Le cron est un outil et un hébergeur web en est un autre. Tu ne trouveras pas non plus de section dédiée à la commande "ls" ou à la commande "mount" qui sont aussi d'autres outils.

Lorsque j'appelle directement la page, tout fonctionne très bien en prod et sur mon environnement de développement, mais cela ne marche pas du tout lorsque le CRON l'appelle ! Je pense que c'est parce que lorsque je lance le script directement, il cherche le fichier au même niveau que lui

Exactement. Et ce n'est même pas un souci lié à cron, c'est un souci de nommage des fichiers Lorsque tu appelles ton script manuellement tu te trouves à l'endroit où se trouve le fichier "toto.txt" et ça fonctionne mais place-toi dans "/tmp" et appelle ensuite ton script même manuellement, il ne fonctionnera plus.

(je pourrais le remplacer par `./toto.txt`, cela ne change rien).

Exact puisque le dossier "." symbolise le dossier où tu te trouves. Donc que le fichier soit appelé depuis implicitement l'endroit où tu te trouves ou que tu lui dises explicitement de prendre le fichier depuis l'endroit où tu te trouves cela ne change effectivement rien.

Afin de résoudre ce problème, je suis obligé d'écrire l'URL absolue

Ben oui. Mais en allant plus loin, afin de résoudre le problème tu es obligé de surtout réfléchir à ce que signifie un nommage relatif et à l'implication que cela a dans les projets.

Cependant, ce code n'est clairement pas idéal, car il ne fonctionne plus sur mon environnement de développement et n'est pas du tout portable en cas de changement d'hébergeur ou même de répertoire.

C'est pour cela qu'il existe des fichiers dit "de configuration", fichiers destinés à donner les chemins de base du projet et sur lesquels les scripts iront taper.
Il y a aussi les variables d'environnement $HOME et $LOGNAME qui référencent respectivement le dossier de base de l'utilisateur et le nom de l'utilisateur et qui sont connues du cron. Pour le reste, on ne travaille jamais en relatif dans un projet parce que justement le relatif c'est relatif à l'endroit où l'utilisateur se trouve lorsqu'il lance le projet. Et qu'un chemin relatif, par définition c'est un chemin qui n'est pas figé et donc qui ne peut pas servir de repère.

[papajoker]

bonjour

C'est toujours la même chose quel que soit le language pour ton problème.
Il faut récupérer le chemin du script(absolu) puis lui ajouter ton fichier(relatif) et on obtient un chemin absolu !

Donc ta question est ici, purement php ... voir (par exemple) la constante __DIR__ (python: __file__, bash: BASH_SOURCE / $0, ...)

/usr/bin/php80 -f /home/sites/11/82103d299/monsite/monscript.php

D'après ce que tu écris, ici ton script est accessible via http Mauvaise pratique ! A toi de le descendre d'un niveau.
Par exemple /home/sites/11/ID_CLIENT/monscript.php ou mieux /home/sites/11/ID_CLIENT/MAINTENANCE/monscript.php

note: oui, le top est d'utiliser une variable d'environnement type HOME, mais elle n'est pas forcément présente chez ton hébergeur au niveau des cron.

----------------------------

C'est pour cela qu'il existe des fichiers dit "de configuration", fichiers destinés à donner les chemins de base du projet et sur lesquels les scripts iront taper.

Pas d'accord justement puisque ici, on ne connait pas son répertoire, il est donc impossible de trouver le fichier de config... (sans variable d'environnement particulière dont tu parles).

[Sve@r]

Ah oui désolé, le chemin du script je n'y ai pas pensé mais c'est effectivement un bon point de réflexion