if [ ! -e $ddext ] || [ ! -e $ddext2 ]
then
echo "Le DDext ne répond pas"
else
[ -d $autre ] || echo "Le dossier de montage n’existe pas !"
read -p 'sauve ou sauve2 ? : ’ part
if [ $part = sauve ]
then
sudo mount -t ext3 $ddext $autre
elif [ $part = sauve2 ]
then
sudo mount -t ext2 $ddext2 $autre
else
echo "mauvaise entree"
fi
fi[/code]
1/ Oui mais ça ne va pas faire une réponse supplémentaire, du genre : “ne peut pas créer,le dossier existe déjà” ?
2/ J’ai déjà modifié pas mal de choses en fonction des précédentes réponses, que je proposerai après mais j’ai besoin encore d’une aide :
comment mettre la sortie sur la même ligne ?
then
echo "Le dossier de montage n'existe pas !"
exit
Si je comprends bien, cette commande ne nécessite rien d'autre puisque :
si '$autre' (le dossier de montage) existe, il passe à la suite
si '$autre' n'existe pas, il le crée
problème : pour créer un dossier, il faut être root, alors que va-t-il faire ?
Si je comprends bien, cette commande ne nécessite rien d’autre puisque :
si ‘$autre’ (le dossier de montage) existe, il passe à la suite
si ‘$autre’ n’existe pas, il le crée
problème : pour créer un dossier, il faut être root, alors que va-t-il faire ?
[quote=“ricardo”]mkdir -p $autre
Si je comprends bien, cette commande ne nécessite rien d’autre puisque :
si ‘$autre’ (le dossier de montage) existe, il passe à la suite
si ‘$autre’ n’existe pas, il le crée
problème : pour créer un dossier, il faut être root, alors que va-t-il faire ?[/quote]
Te balancer une erreur comme quoi il n’a pas les droits suffisants.
Conseil : protège la variable avec des double guillemets :
Comme ça si autre contient un espace, il créeras un dossier avec un espace dedans et pas deux dossiers.
[quote=“MisterFreez”]Et pour l’histoire (au sujet de mon dernier conseil), un patch qui a fait le tour de monde il n’y a pas très longtemps était celui-ci :
echo "Le dossier de montage n'existe pas !" && exit[/quote]
Oui mais la ligne est plus longue que ça.
Je voudrais savoir si et comment on peut faire que le ‹ && › ne soit pris en compte que pour ce qui est après le ‹ || › et non avant.
ligne complète :
Autrement dit, si $variable est présent, que ça ne sorte PAS.
Cette syntaxe n’executera le exit 1 que si la variable n’existe pas :
[ -e "$variable" ] || ( echo "Le dossier de montage n'existe pas " && exit 1 )[/quote] Ben non, si la variable n’est pas bonne, il continue sans sortir (copié/collé) :
[ -e "$variable" ] || ( echo "Le dossier de montage n'existe pas !" && exit 1 )
[quote=« ricardo »]
Je voudrais savoir si et comment on peut faire que le ‹ && › ne soit pris en compte que pour ce qui est après le ‹ || › et non avant.
ligne complète :
Autrement dit, si $variable est présent, que ça ne sorte PAS.[/quote]
Il faut que tu inclus tes 2 instructions dans un bloc et dans le même contexte. Un bloc se constitue avec des accolades :
[ -e "$variable" ] || {
echo "Le dossier de montage n'existe pas !"
exit 1
}
si l’accolade de fin se trouve sur une ligne avec instruction, il faut que la dernière instruction soit suivie d’un point-virgule :
[ -e "$variable" ] || { echo "Le dossier de montage n'existe pas !"; exit 1; }
Les parenthèses peuvent également être utilisées pour créer un bloc. Cependant, elles crées également un processus fils. L’emploi d’un exit dans un processus fils permet de quitter le processus fils et non le processus père. Ce n’est donc pas ce que tu souhaites.
A l’inverse des accolades, le point-virgule en fin de bloc n’est pas nécessaire.
edit : aussi, il est d’habitude d’envoyer les messages d’erreur sur la sortie…d’erreur !
[ -e "$variable" ] || { echo "Le dossier de montage n'existe pas !" >&2; exit 1; }
# ou bien
[ -e "$variable" ] || { echo "Le dossier de montage n'existe pas !"; exit 1; } >&2
Merci à vous deux
Totor, tu as devancé la question que je voulais poser ensuite avec la façon d’ajouter le retour de code d’erreur
Mais j’ai encore deux questions sur le domaine des codes.
1/ quand plusieurs ‹ exit › sur un script, doit-on changer le code à chaque ‹ exit › ?
et celui de « fin », comment le rédiger ?
1/ Non, tu n’es pas obligé. Il est bon regrouper ses codes erreur par “type” : technique en rapport avec des accès disques, erreur technique en rapport avec le réseau …etc (mais également fonctionnel) Ensuite, le message est là pour apporter des précisions et orienter l’utilisateur.
Pour celui de fin, il n’est pas nécessaire. S’il n’existe pas, le statut ne vaut pas forcément 0 mais vaut celui de la dernière instruction exécutée (Contrairement à ce que beaucoup de développeurs pensent).
2/ Je ne connaissais pas cette classification et j’avoue que j’ai tendance à utiliser mes propres statuts.
Explication :
le 2 est le n° du descripteur de fichier (fd) de la sortie d’erreur (dont le fichier associé est /dev/stderr)
le signe “>” indique une redirection de flux. Par défaut, on redirige la sortie standard. Mais l’on peut préciser le flux à rediriger
exemple : 2>&1 où là on fait l’inverse : on redirige la sortie d’erreur vers la sortie standard (fd de la sortie standard=1).
le & préciser que l’on redirige vers un fd. Si le & est absent, on redirige vers un fichier…
il existe 3 fd par défaut :
0 - entrée standard
1 - sortie standard
2 - sortie d’erreur
Non, tes explications me suffisent, je n’ai pas l’intention de devenir prof d’info à mon âge Mais j’aime bien comprendre un minimum ce que je fais.
Merci.
Y’en aura certainement d’autres
:
Mais j’aime bien comprendre un minimum ce que je fais.