Bonjour,

Vous me conseillez plutôt  d'utiliser ce genre  d'ecriture 

IF [CONDITION];then
echo "erreur ..."
ELSE
suite du script
FI

ou

IF [CONDITION];then
echo "erreur ..."
exit
FI
Suite du script 

-
Edité par bbsebb 3 septembre 2019 à 0:57:25

he, he, mais ça dépend de ce que tu veux faire !

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.

La raison est que ça donne, dans ce cas, du code "à plat" beaucoup plus facile à maintenir qu'une imbrication de N niveaux de if.

 Sinon, mais ce n'était sans doute pas la question, il faut indenter

if [ $# != 2 ] ; then
   echo "pas le bon nombre d'arguments"
   exit 1
fi

-
Edité par michelbillaud 3 septembre 2019 à 9:44:58

michelbillaud a écrit:

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. 

Merci

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

rappelons que les noms de variables tout en majuscules sont, par convention, réservés aux variables d'environnement (HOME, USER...).

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.

Exemple celui ci n'en parle pas https://lug.fh-swf.de/vim/vim-bash/StyleGuideShell.en.pdf

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

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).

michelbillaud a écrit:

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