Apprendre � ma�triser les conditions en bash [Tutoriel]

Bonjour,

Par ailleurs, on trouvera des crochets en lieu et place des habituelles parenth�ses.

non.
d'ailleurs "habituelles" par rapport � quoi ?
la syntaxe de if est

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

 if COMMANDES; then COMMANDES; [ elif COMMANDES; then COMMANDES; ]... [ else COMMANDES; ] fi

c'est-�-dire que les crochets, en fait, sont une commande, et plus exactement un synonyme de la commande test.
donc, il est possible d'�crire

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

if grep -q ":${USER}:" /etc/passwd; then echo "$USER est un utilisateur"; else echo "$USER n'est pas un utilisateur"; fi

c'est pourquoi on est quelques uns � pr�coniser l'emploi de test, plut�t que les crochets, pour �viter ce contresens. � un caract�re pr�s , c'est �gal, et plus �loquent.


il vaut mieux ne pas utiliser == avec test pour ne pas confondre le comportement qu'ils ont entre double crochets.


c'est bien de souligner que, lorsqu'on emploi la commande test (ou son synonyme), les variables doivent toujours �tre mises entre guillemets. si, si, c'est une obligation, sous risque d'erreur; tu l'indiques justement.
ce n'est pas le cas pour les doubles crochets. (voir plus bas)

un simili d'expression r�guli�re

pourquoi "simili" ?

il est possible d'omettre les guillemets autour des variables, car les espaces ne causent plus probl�me. C'est cependant une bonne habitude � conserver, car ailleurs dans les scripts, il est plus prudent de les mettre.

bof.


les conditions simples ne requi�rent pas if.
pour reprendre mon exemple pr�c�dent :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

grep -q ":${USER}:" /etc/passwd && echo "$USER existe" || echo "$USER n'existe pas"

Bonjour,
Bravo pour ce travail, juste une remarque de langage et sur l'exemple choisi :

Seul exemple en anglais parmi les autres termes fran�ais (on peut par exemple citer le terme courant anglais en introduction de paragraphe) :

II-A-2. Conditions sur les strings
et l'exemple choisi est "ta m�re"

On parle bien de cha�ne de caract�res...

Disons que c'est l'association string et ta m�re qui m'a surpris (mais pas "choqu�") dans un premier temps.
Ensuite, je n'ai aucune l�gitimit� "morale" sur ton travail, mais disons que par les temps qui courent il me semble plus judicieux d'utiliser un exemple "moins sexiste" et qui aura tendance � mal vieillir.

Je crois savoir que l'univers GNU / Linux est rempli de gens avec le sens de l'humour et qui aiment la nature, on y croise des gnous, des pingouins, des manchots, des renards, des pandas roux, des cam�l�ons, etc.

Bonjour.

Je plussoie pour l'impr�cision de la phrase "Par ailleurs, on trouvera des crochets en lieu et place des habituelles parenth�ses."

Originellement [ est une commande ind�pendante de l'instruction shell if (il s'agit d'ailleurs d'un fork de la commande test) qui renvoie succ�s (0) si l'expression bool��nne est vrai et �chec (1) si l'expression bool��nne en param�tre est fausse :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
ineumann ~ $ [ "u" = "v" ]
ineumann ~ $ echo $?
1
ineumann ~ $ [ "u" = "u" ]
ineumann ~ $ echo $?
0

On la retrouve d'ailleurs dans /bin sur certains OS :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
ineumann ~ $ ls -l /bin/[
-rwxr-xr-x. 1 root root 53264 Oct 31  2016 '/bin/['

Dans les versions modernes de bash c'est un builtin au m�me titre que [[ qui est bien souvent pr�f�rable, voir ceci : Prot�ger ses op�randes

En outre if lui test le retour d'une commande (si retour 0 alors on rentre dans le if, sinon non de m�me que pour the_cmd && echo "ok" || echo "ko", syntaxe que vous pourriez aborder d'ailleurs) et donc pas forcemment uniquement [ : if grep, if test, ...

Bref, on a l'habitude de ne pas faire d'approximations ou d'affirmations fausses dans les cours de developpez.com m�me si les intentions sont louables, cela peux conduire � des erreurs de compr�hensions qui peuvent parfois �tre g�nantes et � l'origine de bugs.

Je plussoie �galement pour le fait que sur une communaut� de professionnel on �vites les phrases comme "ta m�re" qui sont � mon sens d�plac�es dans un cours r�dig� � l'usage de professionnels. Dans une formation interne entre coll�gues et sur des slides � la limite on peu se permettre d'�tre "fun" � sa mani�re mais dans un cours ou ouvrage r�dig� et pour une grande audience, c'est inappropri�.

En l'�tat je ne vois pas bien la valeur ajout�e par rapport aux autres cours sur le Shell qui sont d�j� pr�sents sur DVP (en particulier celui de Fr�d�ric dans lequel figure tout le contenu de vos explications avec moins d'impr�cisions). Par contre si vous d�taillez davantage les explications � partir de nos messages, cela pourrait avoit un int�r�t.

Bien � vous,
Idriss