Le second forme est une bonne solution, en début de script, pour passer en revue les raisons de terminer tout de suite.
Genre pas le bon nombre d'arguments, fichier qui n'existe pas, etc.
C'est exactement pour cela que je posais la question. Ça fait de trop grande imbrication c'est compliqué à lire et je voulais savoir si ce n'était pas une mauvaise idée d'utiliser des exit.
Je n'ai pas compris le indenter, je vais tt façon me renseigner sur le exit.
indenter, c'est décaler vers la droite, proportionnellement au niveau d'imbrication
(contre) Exemple, travail de goret
#!/bin/bash
if [ $# -lt 1 ] ; then
echo "Usage: $0 projet1 ..."
exit
fi
TMPDIR=$(mktemp -d)
for DIR ; do NAME=$(basename "$DIR")
cp -r $DIR "$TMPDIR/$NAME"
done
Travail propre
#!/bin/bash
if [ $# -lt 1 ] ; then
echo "Usage: $0 projet1 ..."
exit
fi
TMPDIR=$(mktemp -d)
#
# Copie des projets
#
for DIR ; do
NAME=$(basename "$DIR")
cp -r $DIR "$TMPDIR/$NAME"
done
cd $TMPDIR
L'exécution de l'instruction exit termine le script. Elle peut comporter un code de retour (par défaut 0, qui signifie habituellement que tout va bien)
- Edité par michelbillaud 3 septembre 2019 à 13:51:56
Les noms de variables en majuscules sont réservés aux variables d'environnement si on a envie qu'ils le soient. Pas une contrainte du langage.
C'est plutôt une bonne idée, mais c'est question de _choix de style_ standard pour le codage des scripts, et ce qui est bien avec les standards, c'est qu'il y en a autant qu'on veut.
c'est une convention tacite (ni un diktat, ni une lubie). c'est une règle de savoir vivre en quelque sorte; on n'est pas obligé de la respecter, mais alors on passe pour une personne mal éduquée.
de la même manière, on n'appelle pas une variable var; on lui donne un nom évocateur de sa "fonction" : nomFichier, listeFichiers...
ce n'est pas parce qu'on ne voit pas une chose qu'elle n'existe pas* : le vent. il y a de nombreux tutos sur le net qui ne sont pas à la hauteur, qui reprennent et propagent des archaïsmes, des pratiques contestables, des contre-sens, des erreurs...
*a contrario, on ne peut pas prouver qu'une chose n'existe pas. :/
- Edité par dantonq 3 septembre 2019 à 18:42:19
Validez la réponse utile « Un problème clairement exposé est à moitié résolu. » Pas de MP technique
Pour les noms de variables significatifs, tout à fait d'accord.
Il vaut quand même mieux que les conventions soient _explicites_, parce qu'elles dépendent - dur-ce que des détails - du groupe de gens avec qui on travaille (confilcting standards, et guerres de style....)
Je vois de plus en plus l'utilisation systématique de "${foo}" au lieu de "$foo" là où autrefois on écrivait $foo, même si on est certain que la variable ne contient pas de caractères perturbateurs (espaces, etc).
Pour les noms de variables significatifs, tout à fait d'accord.
Il vaut quand même mieux que les conventions soient _explicites_, parce qu'elles dépendent - dur-ce que des détails - du groupe de gens avec qui on travaille (confilcting standards, et guerres de style....)
Je vois de plus en plus l'utilisation systématique de "${foo}" au lieu de "$foo" là où autrefois on écrivait $foo, même si on est certain que la variable ne contient pas de caractères perturbateurs (espaces, etc).
débutant, j'ai d’ailleurs eu beaucoup de problème avec ${foo} "$foo" et $foo. Heureusement, il y a la doc fr et qql page (plus beaucoup d'erreur ^^) je commence à gérer. J'ai l'impression que Bash a pas mal évolué depuis la création du tuto sur ce site.
Vu que j'utilise les shell scripts (csh, tcsh, sh, ksh puis bash) depuis les années 80, je peux confirmer que ça change pas mal :-) et que les tutos/bouquins d'il y a 20 ans ou plus (les tutos pompent souvent les uns sur les autres) sont bourrés de conseils/exemples qui correspondent de nos jours à des modèles de mauvaises pratiques.
C'est devenu particulièrement pénible avec l'apparition des systèmes de fichiers qui autorisent les espaces et autres caractères dans les noms de fichiers. La simplicité d'écriture (déjà pas géniale) en a pris un coup.
Edit: on peut (parfois) prouver que quelque chose n'existe pas. Par exemple on peut prouver qu'il n'existe pas d'algorithme permettant de déterminer si une affirmation est vraie, ou pas. Théorie de la decidabilité, qui fait la joie des étudiants en informatique.
- Edité par michelbillaud 9 septembre 2019 à 21:13:44
Conseil script bash
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
<< On n'apprend bien qu'à force de se tromper. >>
Validez la réponse utile « Un problème clairement exposé est à moitié résolu. » Pas de MP technique
<< On n'apprend bien qu'à force de se tromper. >>
Validez la réponse utile « Un problème clairement exposé est à moitié résolu. » Pas de MP technique
Validez la réponse utile « Un problème clairement exposé est à moitié résolu. » Pas de MP technique
<< On n'apprend bien qu'à force de se tromper. >>