Vérification automatique de programme shell

Version imprimable

14/03/2013, 08h00
kromei

Vérification automatique de programme shell

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

Bonjour.

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

Exemple :
Code:

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

14/03/2013, 12h03
jack-ft
Citation:

Envoyé par 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é.

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

Citation:

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"...).

Citation:

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:

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:

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!).
14/03/2013, 14h29
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?
14/03/2013, 14h59
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:

ErreursScript=$(ksh -n MonScript 2>&1)
14/03/2013, 15h41
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
14/03/2013, 16h57
jack-ft

Citation:

Envoyé par 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..

oui

Citation:

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?