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, de rappeller les différences notables avec bash et de fournir quelques [[Shell secours|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. Des bases de shell et d'un autre langage de programation peut s'avérer utile. "Voir le site du zéros":http://www.siteduzero.com/informatique/tutoriels/reprenez-le-controle-a-l-aide-de-linux pour un tuto orienté vers les débutants.

{{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 un simple 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 options (qui modifient la façon dont la commande se comporte : affiche de l'aide, beaucoup d'information, etc.) de deux types :

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

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

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

{{tip(Certains paramètres 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))}}

Les commandes peuvent aussi prendre des arguments qui permettent de savoir comment s'exécuter. Ils se placent après les paramètres.

Exemple : @ls -R ~/Documents@. Par défaut, @ls@ ne liste que les fichiers et dossiers dans le dossier courant. L'option @-R@ permet de descendre dans tous les dossiers. L'argument "~/Documents" permet d'exécuter la commande dans le dossier ~/Documents sans s'y déplacer.

{{tip(Pensez à la commande man qui prend comme argument une autre commande et affiche son manuel)}}

h2. Valeurs de retour des commandes et exceptions

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 courantes 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é.

Vous pouvez connaître la valeur de retour de la dernière commande exécutée avec la variable @$?@.

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@. On peut également utiliser des @elif@.

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 ]@ *Notez les espaces !*

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

{{tip(On peut également faire des ET avec && et des OU avec ||. Ces opérateurs ne sont pas spécifiques à la fonction test, ils font parti du langage. Il est donc tout à fait possible de les utiliser [[Petit_precis_de_shell#ET-et-OU-dans-le-langage|sans la fonction test]].)}}

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

*Tests sur les chaînes de caractères*

|_. Argument |_. Signification |

| = | égalité |

| -z | chaîne vide |

| -n | chaîne non vide |

{{Important(Lors des tests de chaîne de caractères, entourez la variable de guillemets. Sinon, si la chaîne est vide, le test ne pourra être effectué)}}

*Tests sur les nombres*

|_. Argument |_. Signification |

| -eq | égalité |

| -ne | différent |

| -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 vraie. 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 `seq [first [incr]] last`@

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ée 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 égal à 1)}}

* $? : 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 paramètres en un seul argument

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

Pour bien voir la différence entre $* et $@, il suffit de regarder la sortie du script suivant : 

<pre>

<code class="bash">

echo 'Avec $*'

for param in "$*" ; do

  echo $param

done

echo 'Avec $@'

for param in "$@" ; do

  echo $param

done

</code>

</pre>

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-fonction () {

  CMDS

}

</pre>

ou encore

<pre>

function nom_de_la-fonction {

  CMDS

}

</pre>

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

* la portée des variables

* la valeur de retour

Par défaut, les variables 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 variable soit locale, il faut utiliser le mot clé @local@ lors de sa définition. Par exemple : @local nom=clubdrupal@ (NB : local est une commande qui peut prendre des options).

Pour qu'une fonction en bash retourne une valeur comme vous pouvez en avoir l'habitude dans d'autres langages, 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

h2. Les flux sortant

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.

h2. Les flux entrant

Il est également possible de passer en paramètre le contenu d’un fichier. Pour cela, on utilise le symbole <.

h1. Importer une configuration

Il est tout à fait possible d'écrire un fichier de configuration contenant les variables et les fonctions indispensables à d'autres scripts et les réutliser facilement dans ceux-ci. Pour cela, respecter la syntaxe shell dans le fichier puis au début du script qui en a besoin, placer la ligne : @. config-file.sh@ pour l'importer.

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

h2. Variables disponibles uniquement en Bash

* RANDOM (pour la génération de nombre aléatoire). Voir [[Shell_secours#Générer-des-nombres-aléatoires|ici]] pour plus de détails.

h2. Syntaxe

* &> et |&. Permettent de rediriger tous les flux vers un fichier ou de passer tous les flux à une commande (pipe généralisé)

* {2..10} pour générer des séquences de nombres

* @[[ ARGS ]]@ : permet de faire des tests de façon plus facile ou agréable. Exemple : @[[ chaine == chaine2 ]]@

* =~ : s'utilse conjointement avec @[[ ]]@ pour tester si la chaîne de gauche est contenu dans celle de droite

* $((ARGS)) est un raccourcis pour la fonction let

h2. Autres

* Le nombre de paramètres en bash n'est pas limité à 9. Les paramètres positionnels de numéros supérieurs à 10 s'appellent comme suit : ${num}

h1. Divers

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

* @ls@ renvoie simplement la liste des fichiers.

* @find@ renvoie un chemin absolu si l’argument donnée est un chemin absolu et relatif (de la forme ./fichier) si l’argument est .

h2. ET et OU dans le langage

L’opérateur && permet de réaliser un ET paresseux entre deux commandes. Ainsi, par exemple : @cmd1 && cmd2@. @cmd2@ ne sera exécuté que si @cmd1@ a pu s’exécuter correctement. En outre le code de retour de l’ensemble ne sera 0 que si les deux commandes ont pu s’exécuter correctement.

L’opérateur || permet de réaliser un OU paresseux entre deux commandes. Ainsi, par exemple : @cmd1 || cmd2@. Si @cmd1@ s’exécute correctement @cmd2@ ne sera pas exécutée. Si @cmd1@ retourne une erreur, @cmd2@ sera exécutée. Le code de retour de l’ensemble correspond à un OU entre les deux codes de retour.

Ceci peut s’utiliser [[Petit_precis_de_shell#La-fonction-test|avec la fonction test]].

Des fonctionnalités analogues existes dans d’autres langages inspirés du shell comme Perl ou PHP.

Pour exécuter simplement deux commandes à la suite des autres sur une seule ligne, il suffit de séparer les commandes par un point virgule.

h2. Différences entre les implémentations de certaines commandes entre GNU et BSD

h3. sed

La commande @sed@ de BSD ne connaît pas certains métacaractères tels que \s.

h1. Sources et liens externes

* http://www.siteduzero.com/informatique/tutoriels/reprenez-le-controle-a-l-aide-de-linux

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