Club Drupal

Le shell est un langage assez particulier qu'on ne connait pas forcément en arrivant à centrale et qu'on a pas forcément l'occasion de beaucoup pratiquer. Le but de ce document est de rappeler les quelques bases du langage et de fournir quelques solutions standard à des problèmes courants afin que le nouveau membre du club Drupal ne soit pas désemparé et puisse comprendre les scripts. Il ne se veut en aucun cas un cours/tuto complet et exhaustif.

{{toc}}

h1. Quelques rappels d'Unix

Le langage shell est le langage de script qui vient par défaut avec _tous_ les Unix. En effet, même si désormais d'autres interpréteurs plus modernes sont désormais répandus (bash, csh, zsh, etc.), ils ont tous conservé la compatibilité avec le shell.

Comme pour la plupart des langages de script, il existe deux façons d'exécuter des instructions shell :

* directement dans l'interpréteur

* dans un script shell

Pour lancer un interpréteur shell, rien de plus simple : lancer un terminal (graphique ou tty). Et oui, le shell comprend toutes les commandes Unix que vous avez vues en début d'année (pwd, cd, cp). Vous pouvez donc les réutiliser _telles quelles_ dans vos scripts et utiliser son bon terminal pour faire des boucles, des conditions et j'en passe.

h1. Les bases du shell

Il est très important de comprendre et de garder à l'esprit qu'en shell tout est :

* chaîne de caractères (y compris les nombres) ! Entrez @echo 1 + 1@ dans le terminal pour vous en convaincre.

* commande et que donc elles peuvent prendre des arguments (cela s'éclaircira plus tard)

h2. Syntaxe de base

Les commandes s'écrivent soit :

* les unes à la suite des autres séparées par ; (peu recommandé)

* séparées les unes des autres par un saut de ligne

Chaque commande peut prendre des arguments de deux types :

* les arguments courts (l, r, h pour @ls@ par exemple) qui sont passés comme suit : @CMD -ARG@

* les arguments longs (recursive pour @rsync@ par exemple) qui se passent comme ceci : @CMD --ARGUMENT@

Il est évidement possible de passer plusieurs arguments à une même commande.

{{tip(Certains arguments existent sous une forme courte et une forme longue. Consulter le manuel de la commande pour plus de détails. Le manuel contient également la liste complète des arguments supportés par une commande.)}}

{{note(Certains commandes ne respectent pas la convention énoncée ce-dessus. Leurs arguments long se passent avec un seul - (find en est un exemple))}}

h2. Valeurs de retour des commandes et exception

Une fois qu'une commande s'est exécutée, elle renvoie une valeur de retour afin "d'informer" l'utilisateur. Cette valeur permet en effet de savoir si la commande s'est exécutée correctement. Voici les valeurs de retour possibles et leur signification :

* 0 : tout va bien

* 1 : erreur

* 2 : erreur grave

Vous pouvez vous aussi utiliser ces valeurs de retour. Par défaut, un script qui se complète correctement retourne 0. Mais vous pouvez (par exemple si un utilisateur tente d'exécuter un script qui nécessite un argument sans) retourner un autre code d'erreur avec la commande @exit@. Il suffit de lui passer le code qu'elle doit retourner. Votre script s'arrêtera alors avec le code d'erreur spécifié.

h2. Exécuter une commande

S’il est facile dans les cas simples d’exécuter une commande, dès lors qu’en shell tout est chaîne de caractères, si vous voulez affecter la sortie d’une commande à une variable, vous ne pouvez pas simplement faire @var=CMD@ car var va alors valoir la chaîne CMD.

Pour obtenir le résultat souhaité vous devez placer CMS entre backquote `` ou entre $(…). Par exemple : @var=`ls`@ ou @var=$(ls)@.

La syntaxe `` serait plus ancienne et supportée partout. La syntaxe $(…) serait plus récente et présente l’avantage de pouvoir imbriquer les commandes sans ambiguïté.

h2. Conditions et itérations

h3. Conditions if … else …

La structure générale d'une condition est la suivante :

<pre>

<code>

if QQC

then

    CMDS

else

    CMDS

fi

</code>

</pre>

Le @else@ est facultatif. Il est aussi possible de regrouper @if@ et @then@ en une seule ligne comme ceci : @if QQC ; then@.

La question que vous devriez avoir est que mettre à la place de @QQC@. Il y a deux possibilités :

* la fonction @test@

* une commande

h4. La fonction test

{{important(Dans toute la suite, il faudra faire très *attention aux espaces*)}}

La fonction @test@ s'utilise en général comme suit : @if [ ARGS ]@

*IMPORTANT* : La syntaxe *@if [[ ARGS ]]@* n'est valide qu'avec *bash*. Voir [[Petit_precis_de_shell#Différences notables avec bash|Différences notables avec bash]]

Pour faire un test, il suffit ensuite de passer les bons arguments à la commande. Par exemple, pour tester si une chaîne est vide : @if [ -z $chaine ]. Si l’argument a besoin de deux paramètres pour fonctionner, mettre un paramètre de chaque côté de celui-ci. Par exemple, pour faire un test d’égalité de chaîne de caractères : @CHAINE1 = CHAINE2@.

On peut aussi combiner les arguments avec des ET et des OU avec les options @-a@ et @-o@. Le caractère "!" permet de faire une négation.

Voir ci-dessous pour la liste complète.

{{important(En shell, tout est chaîne de caractère. Bien faire attention au type que l’on veut tester (chaîne ou nombre))}}

h5. Tests sur les chaînes de caractères

|_. Argument |_. Signification |

| = | égalité |

| -z | chaîne vide |

| -n | chaîne non vide |

h5. Tests sur les nombres

|_. Argument |_. Signification |

| -eq | égalité |

| -ne | non égalité |

| -lt | strictement plus petit |

| -gt | strictement plus grand |

| -ge | plus grand ou égal |

| -le | plus petit ou égal |

h4. Test avec une commande

Comme indiqué précédemment, une commande qui s’exécute correctement est considérée comme vrai. Ainsi, il est tout a fait possible, par exemple, pour savoir si on arrive à se connecter à un serveur mysql de faire simplement : @if mysql -h HOST -u asso -pTATA@.

{{tip(Parfois vous pourrez rencontrer des problèmes. Pensez alors à donner cette commande en argument à la fonction test)}}

h3. Boucles while/until

La structure générale est la suivante :

<pre>

while QQC

do

    CMD

done

</pre>

Il est possible de regrouper @while QQC@ et le @do@ en @while QQC ; do@. Le QQC peut être remplacer par exactement les mêmes choses que pour la condition. Se référer à cette section pour les précisions.

Le shell propose également le mot clé @until QQC@ qui fait une action jusqu’à ce que QQC soit réalisé.

h3. Boucle for

L’utilisation de la boucle for en shell ressemble à celle de python. La structure générale est la suivante :

<pre>

for var in `CMD`

do

   CMD

done

</pre>

La variable _var_ va alors prendre une à une les valeurs données par CMD. Par exemple, @for file in `ls`@ la variable var va prendre tour à tour le nom de tous les fichiers et dossiers donnés par la commande @ls@.

Vous pouvez également utiliser for pour boucler d’un nombre à un autre avec la syntaxe : @for i in {2..9}@

{{warning(2..9 semble être du bash. à revoir)}}

h1. Paramètres de scripts

h2. Généralités

Un script peut prendre des paramètres qui ont le même but que les arguments d'une fonction : lui passer des informations. Un paramètre peut être :

* une variable

* une chaîne de caractère (donc un nombre, en shell on ne fait pas la distinction). Si la chaîne à passer en paramètre contient plusieurs mots séparés par des espaces, ne pas oublier de la mettre entre ' ou ".

{{tip(Si une varaible coucou contient la chaîne 'salut', alors '$coucou toi' sera compris _$coucou toi_ tandis que "$coucou toi" sera interprété en _salut toi_)}}

Les paramètres se passent à un script comme ceux d'une commande. Ils sont ensuite disponibles dans l'ordre avec des numéros :

* le premier : $1

* le deuxième : $2

* et ainsi de suite

{{important(Le shell ne supporte *que* 9 paramètres)}}

h2. Les paramètres spéciaux

* $0 : contient le nom du script

* $# : contient le nombre d'arguments passés au script

{{important(Le paramète $0 est toujours passé au script. $# est donc toujours supérieur ou égale à 1)}}

* $* : l'ensemble des paramètres en un seul argument A DETAILLER

* $? : le code de retour de la dernière commande invoquée

* $$ : le PID du shell qui exécute le script

* $! : le PID du dernier processus lancé en arrière plan

* $@ : L'ensemble des arguments, un argument par paramètre A DETAILLER

h2. Les commandes shift et set

La commande @set@ permet d'affecter les paramètres. Ainsi @set bonjour salut bonsoir@ va initialiser $1 à bonjour, $2 à salut et $3 à bonsoir. Les paramètres spéciaux $#, $* et $@ sont mis à jour.

La commande @shift@ permet de décaler les variables. Ainsi, si après @shift@ $1 prend la valeur de $2 et ainsi de suite. @shift n@ décale les arguments de n

h1. Les fonctions

Il est tout à fait possible de définir en shell des fonctions que ce soit dans un script ou un terminal. La syntaxe est la même.

<pre>

nom_de_la-foncion () {

  CMDS

}

</pre>

Les fonctions ainsi créées s'utilise comme les commandes classiques et leurs arguments se manipulent exactement comme ceux d'un script. Voir [[Petit_precis_de_shell#Les-redirections-de-flux|la section dédiée]]. Il faut néanmoins faire attention à deux points :

* la portée des varibles

* la valeur de retour

Par défaut, les varialbes définies dans la fonction resteront accessibles une fois la fonction exécutée. De même les varables définies auparavant restent acessibles dans la fonction. *Ces varaibles sont donc globales par défaut.* Pour qu'une variables soit locale, il faut utiliser le mot clé @local@ lors de sa définition. Par exemple : @local nom=clubdrupal@.

Pour qu'une fonction en bash retourne une valeur comme vous pouvez en avoir l'habitude dans d'autre langage, il faut utiliser la commande @echo@. En effet, il n'existe pas d'instruction @return@ puisque par défaut les variables sont globales. Il faut alors faire très attention. Par exemple avec la fonction suivante :

<pre>

<code class="bash">

x_files () {

  top_secret=`dd if=/dev/urandom count=1 2> /dev/null | cksum | cut -f1 -d" "`

  echo $top_secret

}

</code>

</pre>

* Si on fait @x_files@ on affiche à l'écran le contenu de @$top_secret@

* Si on fait @passwd=`x_files`@ on affecte à la variable @$passwd@ le contenu de @$top_secret@

h1. Les redirections de flux

Les flux représentent les sorties générées par les commandes. Par défaut, il existe deux flux :

* Le flux standard

* Le flux d'erreur

Par défaut, il s'affiche sur la sortie standard (votre écran pour être bref). Il peut s'avérer intéressant d'envoyer ces flux ailleurs (logs, le néant, etc.). Pour cela, on va les rediriger. Par exemple pour rediriger la sortie de @ls@ dans un fichier nommé toto, on fait :

* @ls > toto@

* *ou*

* @ls >> toto@

La première solution efface le contenu du fichier puis écrit dedans. La seconde ajoute la sortie à la fin du fichier. On a ici redirigé le flux standard. Pour rediriger les flux d'erreurs, on utilise les symboles @2>@ ou @2>>@. On peut évidemment combiner les deux : @ls -R / > mes_fichiers.txt 2> errors.log@ avec toutes les variantes possibles.

Pour rediriger l'erreur au même endroit que l'entrée, on peut faire @ls > toto 2> toto@ ou plus simplement @ls > toto 2>&1@.

Pour rediriger une sortie vers le néant, on l'envoie dans /dev/null.

h1. Importer une configuration

@. config-file.sh@

h1. Mode debug

Lorsqu’un de vos scripts shell bug il peut être difficile de savoir d’où vient le problème. Heureusement, le shell propose un mode débug qui vous dit pour chaque ligne comment elle est exécuté, avec quels paramètres (les variables sont remplacées par leur contenu).

Il suffit de faire : @sh -x SCRIPT@

h1. Différences notables avec bash

* RANDOM

* let

* &> et |&

* le nombre de paramètres

h1. Divers

h2. Différences entre la sortie de ls et de find

ls : chemin relatif ; find auei : chemin absolu

h1. Sources et liens externes

* http://www.commentcamarche.net/faq/5444-bash-les-parametres