Discussion :

[kromei]

Bonjour,
Je suis actuellement responsable d'une application qui exécute automatiquement des scripts shell. Il y a un certain nombre de scripts qui tournent et il peut m'arriver d'avoir fait une erreur technique lors d'une mise à jour de script par exemple ou encore que le script ne fonctionne plus suite à une mise à jour ailleurs.

Je me demandais donc si il était possible, à partir d'un script existant qui lance tous les autres, de vérifier qu'un script shell c'est bien déroulé. Le niveau de vérification ne serait pas énorme mais ça serait de l'ordre de la detection automatique des erreurs types operator unexpected ou encore le "il manque une cote ect.. je ne souhaite même pas forcément relever l'erreur en elle même mais juste voir si le script est allé du début à la fin d'un fonctionnement

Merci de vos réponses

[ok.Idriss]

Bonjour.

Il est possible déjà de tester le retour de vos scripts avec la variable $?

Exemple :

Code :

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

1
2
3
4
5
6
7
8
idriss@ThinkPad-T420 /var/www/National/shell $ [ "toto" -ne 3 ] && echo "ok"
bash: [: toto: integer expression expected
idriss@-ThinkPad-T420 /var/www/National/shell $ echo $?
2
idriss@ThinkPad-T420 /var/www/National/shell $ [ "toto" != "3" ] && echo "ok"
ok
idriss@ThinkPad-T420 /var/www/National/shell $ echo $?
0

0 quand ça c'est bien déroulé en d'autres termes

Cordialement,
Idriss

[jack-ft]

Bonjour,
Je suis actuellement responsable d'une application qui exécute automatiquement des scripts shell. Il y a un certain nombre de scripts qui tournent et il peut m'arriver d'avoir fait une erreur technique lors d'une mise à jour de script par exemple ou encore que le script ne fonctionne plus suite à une mise à jour ailleurs.

Je me demandais donc si il était possible, à partir d'un script existant qui lance tous les autres, de vérifier qu'un script shell c'est bien déroulé.

C'est un problème très délicat (c'est très proche de ce sur quoi je travaille en ce moment).

Le niveau de vérification ne serait pas énorme mais ça serait de l'ordre de la detection automatique des erreurs types operator unexpected ou encore le "il manque une cote ect.. je ne souhaite même pas forcément relever l'erreur en elle même

Pour ça, tu peux, par exemple (et à peu de frais), récupérer la stderr de chaque script appelé et chercher avec grep quelques chaines type à déterminer (comme "operator unexpected " "not found"...).

mais juste voir si le script est allé du début à la fin d'un fonctionnement

ça, c'est vraiment un gros problème lié au shell: lorsqu'une "erreur" se produit, le script continue comme si de rien n'était et peut même terminer avec un bon status de 0 (si la dernière instruction s'est bien déroulée).

En effet, si une commande (genre 'cp') échoue ou n'est pas trouvée, elle affiche un message sur la stderr et retourne, par exemple, 1. Si la commande suivante ne teste pas le retour du 'cp', le script va continuer tranquillement et peut provoquer des erreurs.

Une manière très radicale d'éviter ça est de lancer les scripts avec l'option -e ou set -o errexit, mais si les scripts n'ont pas été pensés dès le départ avec cette option, c'est voué à l'échec!

De même, si une variable a été "oubliée" ou s'il y a une erreur sur un nom de variable, l'expansion retourne une chaine vide. Parfois, c'est gênant:

Code :

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

1
2
le_repertoire=/tmp/test_dir
rm -rf ${le_repertore}/*

ne va certainement pas dire: "il manque un 'i' à 'le_repertore'"...
Je vous laisse imaginer (avec effroi!) ce qui va se passer. N'ESSAYEZ PAS POUR VOIR! (surtout si vous êtes en root!!!)
Pour éviter ça, on peut positionner l'option 'unset' ou 'nounset' suivant les systèmes:

Code :

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

1
2
3
set -u
set -o nounset
set +o unset

Le seul cas favorable par défaut est lorsqu'un script n'est pas bien "formé" (genre 'fi' sans 'if', ou 'if' sans 'then', etc.). Généralement, il s'arrête (en ayant commencé son exécution ou pas (suivant les systèmes)) et retourne un status différent de 0. (j'ai eu une fois le cas d'un guillemet mal fermé dans une backquote qui a été difficile à trouver!)

Bref, y a plein de cas différents et pas de solution miracle (à ma connaissance!).

[kromei]

Merci de vos réponses

D'accord donc comme je l'ai bien compris en me penchant sur le soucis, le script est interprété comme un ensemble de commande et le code de retour retourné n'est pas forcément valable pour tout le script mais il est plutôt propre à la dernière commande avant la fin de l’exécution de ce dernier..

Est ce que pour un script Shell les codes d'erreurs sont tous fatals (bloquants l’exécution) ou ceux-ci peuvent être un warning ( un echo qui affiche un peu mal ) ?

Et j'ai pensé à utiliser dans un script appelant tous les autre le test ksh -n monscript. J'aurai fortement apprécié le mettre dans une variable mais celui-ci s'obstine à s'afficher sur la console . Est ce une bonne approche d'utiliser cette commande et y a t il une solution pour "variabiliser" le résultat?

[al1_24]

Les résultats de ksh -n (comme -x ou -v) s'affichent sur le périphérique d'erreur (err) et non celui de sortie (out).
Il faut donc rediriger l'erreur vers la sortie pour la "variabiliser"

Code :

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

ErreursScript=$(ksh -n MonScript 2>&1)

[kromei]

ça me va pour le moment j'essai de réfléchir si pour un shell il existe un cas d'affichage non bloquant mais je n'en vois pas

Merci

[jack-ft]

Merci de vos réponses

D'accord donc comme je l'ai bien compris en me penchant sur le soucis, le script est interprété comme un ensemble de commande et le code de retour retourné n'est pas forcément valable pour tout le script mais il est plutôt propre à la dernière commande avant la fin de l’exécution de ce dernier..

oui

Est ce que pour un script Shell les codes d'erreurs sont tous fatals (bloquants l’exécution) ou ceux-ci peuvent être un warning ( un echo qui affiche un peu mal ) ?

Je ne suis pas sûr de bien comprendre la question ?!?
Tu as lu mon post?
Pour le résumer et utiliser ton vocabulaire: aucun code d'erreur n'est fatal/ne bloque l'exécution. C'est bien justement le souci!
Peux-tu préciser ta question?