Rechercher : dans
Par :

[Shell] - Gestion des erreurs

Dernière réponse le 13 jun 2007 à 16:55:08 gorkimat, le 12 jun 2007 à 22:30:19 
 Signaler ce message aux modérateurs

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

Configuration: Linux
Konqueror 3.5

Meilleures réponses pour « [Shell] Gestion des erreurs » dans :
Gestion des erreurs VoirPar défaut, en Pascal, la gestion des erreurs est assurée par le compilateur. C’est pour cette raison que le programme s’arrête en affichant un message commençant par Runtime error suivi par le numéro de l’erreur … Alors si le programmeur désire...
Codes d'erreur de Windows VoirLa liste ci-dessous détaille les codes d'erreur s'affichant dans les boîtes de dialogue sous Windows : Code Description ------------------------ 1 Fonction incorrecte. 2 Le fichier spécifié est introuvable. 3 Le chemin d'accès spécifié...
Guide d'utilisation du Shell pour débutant VoirSHELL BASH - GUIDE D'UTILISATION - Niveau Débutant Introduction Appel aux membres CCM II. C'est quoi le shell ? III. Comment accéder à la ligne de commande IV. Les consoles virtuelles Exemple : Accéder à la console 3 depuis l'interface...
Systèmes UNIX - Le shell VoirIntroduction au shell L'interpréteur de commandes est l'interface entre l'utilisateur et le système d'exploitation, d'où son nom anglais «shell», qui signifie «coquille». Le shell est ainsi chargé de faire l'intermédiaire entre le système...
Gestion des erreurs et exceptions VoirGestion des erreurs et exceptions Les lignes de code que vous avez étudiées jusqu’à présent ne constituaient pas de vrais programmes mais des exemples. Elles ne comprenaient donc aucun traitement des erreurs. Les programmes que vous développerez...
Enterprise Resource Planning (ERP) - Progiciel de Gestion Intégr VoirIntroduction aux ERP Les ERP (en anglais Enterprise Resource Planning), aussi appelés Progiciels de Gestion Intégrés (PGI), sont des applications dont le but est de coordonner l'ensemble des activités d'une entreprise (activités dites verticales...

1

jee pee, le 12 jun 2007 à 22:35:51

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

Répondre à jee pee

2

gorkimat, le 13 jun 2007 à 13:50:57

Bonjour jee pee,

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

Répondre à gorkimat

3

jipicy, le 13 jun 2007 à 14:00:21

Salut,

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 :

jp@MDK:~/tmpfs ssh$ touch deplacer.txt

jp@MDK:~/tmpfs ssh$ ls
deplacer.txt

jp@MDK:~/tmpfs ssh$ mv deplacer.txt deplacer.txt
mv: `deplacer.txt' et `deplacer.txt' identifient le même fichier.

jp@MDK:~/tmpfs ssh$ echo $?
1

jp@MDK:~/tmpfs ssh$ mv deplacer.txt deplacer.txt 2>/dev/null

jp@MDK:~/tmpfs ssh$ echo $?
1
jp@MDK:~/tmpfs ssh$
;-))
Z'@+...che.
JP : Zen, my Nuggets ! ;-)
Le savoir n'est bon que s'il est partagé.

Répondre à jipicy

4

dubcek, le 13 jun 2007 à 14:01:37

Par essence, toutes les commandes sont dangereuses:
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.

Répondre à dubcek

5

jee pee, le 13 jun 2007 à 14:48:40

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 !

Répondre à jee pee

6

gorkimat, le 13 jun 2007 à 16:13:36

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

Répondre à gorkimat

7

jipicy, le 13 jun 2007 à 16:49:05

Tu peux sortir ;-))
Z'@+...che.

JP : Zen, my Nuggets ! ;-)
Le savoir n'est bon que s'il est partagé.

Répondre à jipicy

8

 gorkimat, le 13 jun 2007 à 16:55:08

Super merci ;-)

Répondre à gorkimat
Collection CommentÇaMarche.net