[Shell] - Gestion des erreurs
Résolu
gorkimat
Messages postés
71
Statut
Membre
-
gorkimat Messages postés 71 Statut Membre -
gorkimat Messages postés 71 Statut Membre -
Bonjour à tous/toute(s),
J'ai une questions qui m'pré-occupe depuis que je dois ecrire des scripts en shell ksh sous Sun pour ma mission. Pourriez-vous m'aider ?
Je travaille pour une entreprise qui est très à cheval sur la gestion d'erreur. Ils voudraient être informer de la commande qui à posé problème.
Du coup, je me pose une question : Est-ce que je dois controler les commandes du type rm, cp, mv, gz, tar ... ou est-ce que ces commandes sont fiables (hormis les problème d'espace disque) ?
Je vous remercie d'avance de votre retour d'experience.
Gorki
J'ai une questions qui m'pré-occupe depuis que je dois ecrire des scripts en shell ksh sous Sun pour ma mission. Pourriez-vous m'aider ?
Je travaille pour une entreprise qui est très à cheval sur la gestion d'erreur. Ils voudraient être informer de la commande qui à posé problème.
Du coup, je me pose une question : Est-ce que je dois controler les commandes du type rm, cp, mv, gz, tar ... ou est-ce que ces commandes sont fiables (hormis les problème d'espace disque) ?
Je vous remercie d'avance de votre retour d'experience.
Gorki
A voir également:
- [Shell] - Gestion des erreurs
- Classic shell - Télécharger - Personnalisation
- Logiciel gestion locative gratuit excel - Télécharger - Comptabilité & Facturation
- Logiciel gestion photo gratuit - Guide
- Gestion des fichiers - Télécharger - Gestion de fichiers
- Gestion autorisation application android - Guide
3 réponses
bonsoir,
par essence, toutes les commandes sont fiables, c'est souvent leur utilisation et les paramètres qu'on donne qui ne le sont pas. Dans l'informatique, l'élément le plus faillible c'est le développeur.
l'idéal, pour répondre à ta question c'est de tester le code retour de chaque commande, ainsi en cas d'anomalie, tu peux rediriger vers un log pour memoriser les erreurs.
cdt
par essence, toutes les commandes sont fiables, c'est souvent leur utilisation et les paramètres qu'on donne qui ne le sont pas. Dans l'informatique, l'élément le plus faillible c'est le développeur.
l'idéal, pour répondre à ta question c'est de tester le code retour de chaque commande, ainsi en cas d'anomalie, tu peux rediriger vers un log pour memoriser les erreurs.
cdt
Non c'est vrai que tester dans les shells tous les codes retours c'est utopique.
Pour chaque script il faut determiner les commandes cruciales, l'export de la base de données, la copie sur bande, ...
Et c'est la qualité de la réalisation du script qui va jouer. Quand tu fais ton mv (pas celui de ton exemple qui est meme fichier meme repertoire !) es tu sûr que dans le répertoire de destination le fichier n'existe pas déjà, tu as dû faire le test avant, le supprimer, ... Le soucis primordial c'est que lorsque tu lances ton shell tu n'est jamais sur que le contexte dans lequel il s'execute est bon au départ. Il faut toujours se prémunir contre l'erreur précédente. Le script A en fin supprime le fichier FIC1. Donc lorsqu'il démarre, il suppose toujours que le fichier n'existe pas, mais ce ne sera pas vrai le jour ou le script A ce sera planté la veille sans aller jusqu'au bout.
Comme indiqué par Dubcek, tous les traitements doivent faire l'objet de logs. Et les logs, ya quelqu'un qui est chargé de les controler !
Pour chaque script il faut determiner les commandes cruciales, l'export de la base de données, la copie sur bande, ...
Et c'est la qualité de la réalisation du script qui va jouer. Quand tu fais ton mv (pas celui de ton exemple qui est meme fichier meme repertoire !) es tu sûr que dans le répertoire de destination le fichier n'existe pas déjà, tu as dû faire le test avant, le supprimer, ... Le soucis primordial c'est que lorsque tu lances ton shell tu n'est jamais sur que le contexte dans lequel il s'execute est bon au départ. Il faut toujours se prémunir contre l'erreur précédente. Le script A en fin supprime le fichier FIC1. Donc lorsqu'il démarre, il suppose toujours que le fichier n'existe pas, mais ce ne sera pas vrai le jour ou le script A ce sera planté la veille sans aller jusqu'au bout.
Comme indiqué par Dubcek, tous les traitements doivent faire l'objet de logs. Et les logs, ya quelqu'un qui est chargé de les controler !
Merci pour ta réponse. Je suis d'accord avec toi, mais cela alourdi considérablement le script. Par exemple :
1) Je sais que le fichier /test/deplacer.txt existe
2) Je sais que le repertoire de destination /destination existe
3) Je fais un 'mv /test/deplacer.txt /test/deplacer.txt'
Est-ce que tu testerais le retour de la commande mv ?
Merci,
Gorki
En voyant ton exemple, je ne ferai que citer notre ami "jee pee" :
par essence, toutes les commandes sont fiables, c'est souvent leur utilisation et les paramètres qu'on donne qui ne le sont pas. Dans l'informatique, l'élément le plus faillible c'est le développeur.
Et en ne faisant qu'appliquer ce que tu as répondu :;-))
rm * tmp ooops un blanc de trop
sans parler en tant que root
rm -rf / tmp/* ooops un blanc de trop
tester tous les codes d'erreurs de toutes les commandes me semble impossible.
par compte, garder un log de l'exécution de chaque script, pourquoi pas.