[Shell] - Gestion des erreurs
Résolu/Fermé
gorkimat
Messages postés
70
Date d'inscription
dimanche 1 avril 2007
Statut
Membre
Dernière intervention
1 mars 2012
-
12 juin 2007 à 22:30
gorkimat Messages postés 70 Date d'inscription dimanche 1 avril 2007 Statut Membre Dernière intervention 1 mars 2012 - 13 juin 2007 à 16:55
gorkimat Messages postés 70 Date d'inscription dimanche 1 avril 2007 Statut Membre Dernière intervention 1 mars 2012 - 13 juin 2007 à 16:55
A voir également:
- [Shell] - Gestion des erreurs
- Classic shell windows 10 français - Télécharger - Personnalisation
- Logiciel gestion photos - Guide
- Hdmi gestion alim ✓ - Forum Matériel & Système
- Efi shell version 2.50 - Forum Windows 10
- Startup.nsh shell ✓ - Forum Windows 10
3 réponses
jee pee
Messages postés
39580
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
17 avril 2024
9 221
12 juin 2007 à 22:35
12 juin 2007 à 22:35
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
jee pee
Messages postés
39580
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
17 avril 2024
9 221
13 juin 2007 à 14:48
13 juin 2007 à 14:48
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 !
gorkimat
Messages postés
70
Date d'inscription
dimanche 1 avril 2007
Statut
Membre
Dernière intervention
1 mars 2012
9
13 juin 2007 à 16:13
13 juin 2007 à 16:13
Bonjour à vous tous,
Merci pour vos eclaircissement, j'y vois déjà beaucoup plus clair.
Jipicy : Franchement là, s'il pouvait y avoir un petit trou où me cacher se serait avec plaisir ;-)
Je crois maintenant avoir bien compris la philosophie de l'histoire et je vous en remercie
A bientôt
Gorki
Merci pour vos eclaircissement, j'y vois déjà beaucoup plus clair.
Jipicy : Franchement là, s'il pouvait y avoir un petit trou où me cacher se serait avec plaisir ;-)
Je crois maintenant avoir bien compris la philosophie de l'histoire et je vous en remercie
A bientôt
Gorki
jipicy
Messages postés
40842
Date d'inscription
jeudi 28 août 2003
Statut
Modérateur
Dernière intervention
10 août 2020
4 894
13 juin 2007 à 16:49
13 juin 2007 à 16:49
Tu peux sortir ;-))
gorkimat
Messages postés
70
Date d'inscription
dimanche 1 avril 2007
Statut
Membre
Dernière intervention
1 mars 2012
9
>
jipicy
Messages postés
40842
Date d'inscription
jeudi 28 août 2003
Statut
Modérateur
Dernière intervention
10 août 2020
13 juin 2007 à 16:55
13 juin 2007 à 16:55
Super merci ;-)
13 juin 2007 à 13:50
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
13 juin 2007 à 14:00
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 :;-))
13 juin 2007 à 14:01
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.