Pourquoi l'utilisation de set -e fait-elle échouer mon script lorsqu'il est appelé dans crontab?

Question

J'ai un script bash qui effectue plusieurs opérations sur les fichiers. Quand un utilisateur exécute ce script, il s'exécute avec succès et affiche quelques lignes de texte, mais lorsque j'essaie de le lancer, il y a des problèmes. Il semble fonctionner (je vois une entrée dans cron log montrant qu'il a été lancé) mais rien ne se passe, il ne sort rien et ne fait aucune de ses opérations de fichiers. Il n'apparaît pas non plus dans les processus en cours d'exécution, il semble donc disparaître immédiatement. Après un dépannage, j'ai trouvé que la suppression de "set -e" résolvait le problème, il fonctionne maintenant à partir du système cron sans problème. Donc ça marche, mais je préfèrerais avoir mis -e activé pour que le script se termine s'il y a une erreur. Est-ce que quelqu'un sait pourquoi "set -e" provoque la sortie de mon script?

Merci pour l'aide,
Ryan

Answer 1

Lorsque votre script fonctionne sous Cron, les variables d'environnement et chemin peuvent être réglés différemment que lorsque le script est exécuté directement par un utilisateur. Peut-être c'est pourquoi il se comporte différemment?

Pour tester ceci: créez un nouveau script qui ne fait rien d'autre que printenv et echo $PATH. Exécutez ce script manuellement, en enregistrant la sortie, puis en l'exécutant comme un travail cron, en sauvegardant cette sortie. Comparez les deux environnements. Je suis sûr que vous trouverez des différences ... un shell de connexion interactif aura eu son environnement mis en place en fournissant un ".login", ".bash_profile", ou un script similaire (selon le shell de l'utilisateur). Cela ne se produit généralement pas dans un travail cron , ce qui est généralement la raison pour laquelle un travail cron se comporte différemment de l'exécution du même script dans un shell de connexion .

Pour résoudre ce problème: En haut du script, soit explicitement défini les variables d'environnement et PATH pour correspondre à l'environnement interactif, ou la source « .bash_profile », « .login », ou un autre script de configuration de l'utilisateur, en fonction de la coque qu'ils utilisent.

Answer 2

Avec set -e, le script s'arrêtera à la première commande qui donne un statut de sortie différent de zéro. Cela ne signifie pas nécessairement que vous verrez un message d'erreur.

Voici un exemple, utilisant la commande false qui ne fait que quitter avec un état d'erreur.

Sans set -e:

$ cat test.sh 
#!/bin/sh 

false 
echo Hello 

$ ./test.sh 
Hello 
$ 

Mais le même script avec set -e sorties sans imprimer quoi que ce soit:

$ cat test2.sh 
#!/bin/sh 

set -e 

false 
echo Hello 

$ ./test2.sh 
$ 

Sur la base de vos observations, il semble que votre script échoue pour une raison quelconque (liée vraisemblablement à l'environnement différent, comme Jim Lewis l'a suggéré) avant qu'il ne génère une sortie.

Pour déboguer, ajoutez set -x au début du script (ainsi que set -e) pour afficher les commandes lors de leur exécution.