Discussion :

[gadj0dil0]

Bonjour,

Y a t-il un moyen de lancer les tâches du crontab en test (sans modifier les horodatages). Sachant que crontab a son propre environnement (il ne connaît pas celui des users me semble t-il,les locales, les chemins des binaires...) il est bien parfois de tester (sans passer par un copié-collé dans le shell).

[jlliagre]

Pour tester un crontab, il n'y a pas d'autre méthode de test fiable.
Le plus simple est de dupliquer la ligne à tester et de planifier une exécution quelques minutes plus tard, puis de supprimer la ligne après.

[srvremi]

Au minimum je teste mes scripts CRON en supprimant le PATH user.

Code :

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

1
2
3
4
5
#!/bin/bash
 
export PATH=""
 
.......

@+
Rémi

[jlliagre]

Heu... c'est un peu extrême comme approche, non ?

Ça t'oblige a mettre le chemin complet pour toutes les commandes (non builtin) utilisées, même les commandes standard alors qu'avec cron, ce n'aurait pas été le cas.

Ce qu'on peut suggérer plutôt, c'est :

Code :

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

1
2
PATH=/bin:/usr/bin
...

PS: pas besoin d'exporter la variable PATH, elle l'est déjà, toujours.

[gadj0dil0]

Merci de votre réponse, pour ma pat dans le crontab je met les chemins complets des binaires, je ne me pose même plus la question surtout avec tous les chemins de php par exemple, et en fonction des différents hébergeurs... PHP n'est pas built-in (core-utils) ok, mais la "base" dépend aussi des distributions. Il y a vraiment 1000 manières de faire les choses :
Merci pour vos réponses

[jlliagre]

1/ Les built-ins, c'est les commandes internes au shell (ex: cd, echo, read), pas core-utils. Il n'y a pas besoin de PATH pour les exécuter.

2/ Tous les systèmes Unix et Unix like disposent d'un certain nombre de commandes standard (définies par POSIX, comme cat, ls, awk, sed, rm, mv, etc. et dont quelques unes sont fournies par core-util sous GNU). Ces commandes doivent obligatoirement être accessibles avec le PATH par défaut. Sous Linux, ces commandes sont soit dans /bin, soit dans /usr/bin (soit les deux).

Ce n'est pas une bonne pratique de mettre le path complet pour chaque occurrence de ces commandes. Par exemple, des commandes comme yes, cut ou expr vont se trouver dans /usr/bin sur certains Unix-like et dans /bin dans d'autres. Il faudra que tu fasses une version de script par système cible, ce qui est absurde.

Pour ne pas avoir ce problème, il suffit de ne pas retirer ces deux répertoires du PATH (et de les laisser en début de PATH) pour qu'elles continuent à être utilisables. Si tu veux gérer le cas où les commandes non standard que tu utilises peuvent se trouver dans des endroits différents suivant les distributions, il suffit d'ajouter la liste des tous les chemins possibles dans ton PATH dans le script appelant :

Code :

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

PATH=$PATH:/opt/phpmachin/bin:/var/phptruc/bin

PS: Dans les forums, pas besoin de se vouvoyer.