Pour aller plus loin avec la ligne de commande

Les arguments passés en ligne de commande - c'est-à-dire lors de l'appel de la commande que constitue le script - sont stockés dans les variables $0, $1, $2, etc.

Ainsi :

#!/bin/sh
echo Arguments "[$0] [$1] [$2] [$3] [$4]"

donne :

$ ./testarg.sh -t bonjour "les amis" 34
Arguments [./testarg.sh] [-t] [bonjour] [les amis] [34]
$

On peut noter qu'à l'instar du langage C, l'argument numéro 0 est le programme à exécuter, ici ./testarg.sh.

Notez en outre l'utilisation des guillemets en ligne de commande. Lors de l'exécution de testarg.sh on utilise ces guillemets pour regrouper les mots les et amis en une seule chaîne de caractères, on peut alors les considérer comme un seul argument.

Pour le traitement des paramètres de la ligne de commande, on dispose également de quelques variables prédéfinies :

• la variable $# contient le nombre d'arguments de la ligne de commande sans compter la commande elle-même - les arguments sont donc comptés à partir de $1;
• les variables $* et $@ contiennent toutes les deux l'ensemble des arguments à partir de $1 mais ont une signification différente lorsqu'elles sont utilisées entre guillemets :

#!/bin/sh
for ARG in "$*" ; do echo $ARG ; done

donne :

$ ./testarg2.sh a b c
a b c
$

dans ce cas l'ensemble des arguments est considéré comme une seule chaîne de caractères et :

#!/bin/sh
for ARG in "$@" ; do echo $ARG ; done

donne :

$ ./testarg3.sh a b c
a
b
c
$

Ici chaque argument est considéré comme une chaîne de caractères à part entière. 

Il existe plusieurs mécanismes permettant d'agir sur les variables :

1. l'aide à l'instanciation de variables ;
2. le traitement du contenu.

Chacun de ces mécanismes suit une syntaxe particulière (la plupart du temps assez difficilement mémorisable !). Voici donc à titre d'exemple quelques-uns des outils(75) correspondants :

• ${N:-4} renvoie la valeur de N si on lui en a affecté une, 4 sinon ; ce qui permet d'utiliser une valeur par défaut ;
• ${N:?msg} renvoie le message d'erreur msg si N n'a pas été instancié et quitte le script ; ceci peut être utile pour tester les arguments de la ligne de commande.

Voici un exemple d'utilisation de ces outils :

#!/bin/sh
NOM=${1:?"vous devez fournir un nom"}
PRENOM=${2:-"djobi"}
echo Qui : $PRENOM $NOM

ce qui peut donner à l'exécution :

$ ./varmod.sh
./varmod.sh: 1: vous devez fournir un nom
$

Le texte ./varmod.sh: 1: doit se comprendre comme : « l'argument n°1 du script varmod.sh est manquant »

$ ./varmod.sh djoba
Qui : djobi djoba
$ ./varmod.sh goulbi goulba
Qui : goulba goulbi
$

Pour ce qui est des outils de traitement de contenu la syntaxe est :

• ${N%motif} et ${N%%motif} suppriment respectivement la plus petite et la plus longue chaîne répondant à l'expression régulière motif, à la fin du contenu de la variable N ;
• ${N#motif} et ${N##motif} suppriment respectivement la plus petite et la plus longue chaîne répondant à l'expression régulière motif, au début du contenu de la variable N.

et voici un exemple très instructif inspiré par Newham et Rosenblatt (1998) :

$ P=/home/local/etc/crashrc.conf.old
$ echo ${P%%.*}  <------- supprime la plus grande chaîne commençant par ‘.'
/home/local/etc/crashrc
$ echo ${P%.*}  <-------- supprime la plus petite chaîne commençant par ‘.'
/home/local/etc/crashrc.conf
$ echo ${P##/*/}  <--------- supprime la plus grande chaîne entourée de ‘/'
crashrc.conf.old
$ echo ${P#/*/}  <---------- supprime la plus petite chaîne entourée de ‘/'
local/etc/crashrc.conf.old
$

Une application de ce type d'outils serait, par exemple, la conversion en salve, de plusieurs fichiers JPEG en TIFF. En supposant que :

• les fichiers portent l'extension .jpg ;
• sont dans le répertoire courant ;
• on dispose d'un utilitaire que l'on nommera convert qui est capable d'effectuer cette conversion ;

on peut alors écrire le script (voir § 3.4.3La structure for de bash pour l'utilisation de la boucle for) :

#!/bin/sh
for F in *.jpg ; do
  convert "$F" "${F%.jpg}.tif"
done

Dans ce script, si la variable F vaut à une itération bidule.1.jpg alors :

• ${F%.jpg} vaut bidule.1, c'est-à-dire le nom du fichier auquel on a supprimé la chaîne .jpg à la fin ;
• {F%.jpg}.tif vaut bidule.1.tif, c'est-à-dire, bidule.1 concaténé avec la chaîne .tif.

Finalement, à cette itération on exécute la commande :

convert bidule.1.jpg bidule.1.tif

Ce principe est très utile dans beaucoup de situations où l'on veut traiter plusieurs fichiers. Par exemple le très classique cas où l'on veut renommer un ensemble de fichiers :

$ ls *.wav
audio1.wav audio2.wav audio3.wav
audio4.wav audio5.wav audio6.wav
audio7.wav audio8.wav audio9.wav
$

Imaginons que l'on veuille renommer ces fichiers sous la forme suivante :

• crescent_x.wav

On peut alors écrire :

#!/bin/sh
for F in audio*.wav ; do
  mv $F crescent_${F#audio}
done

Un moyen mnémotechnique de se souvenir de la syntaxe de ces opérateurs est la suivante : # désigne en anglais le numéro (number) et on dit généralement « numéro 5 »; # supprime donc en début de chaîne ; inversement on dit généralement « 5 % » , % supprime donc en fin de chaîne. Le nombre de caractères # ou % rappelle si on supprime la plus petite (1 caractère) ou la plus longue (2 caractères) chaîne correspondant au motif.
'Tain c'est pô convivial ce bazar ! 

Bien que les variables du shell ne soient pas typées, on peut cependant évaluer des expressions arithmétiques ; ces expressions n'auront un sens que si les contenus des variables sont des valeurs numériques, bien entendu. La syntaxe pour évaluer une expression arithmétique est :

• $[expression_arithmétique]

ou

• $((expression_arithmétique)) (à préférer)

Par exemple :

$ N=3
$ echo $((N+1))
4
$ N=$[N+4]
$ echo $N
7
$

Pour illustrer l'utilisation de l'arithmétique sur les variables, considérons par exemple que l'on dispose d'un ensemble de fichiers dont les noms ont la forme suivante :

$ ls *.dat
2002-qsdfff.dat 2002-sdhjlk.dat 2002-yuiqso.dat
2003-azerzz.dat 2003-sddfg.dat 2003-qsdfrtuy.dat
2003-ertyf.dat 2004-ersssty.dat 2004-sdf.dat
...
$

c'est-à-dire :

• année sur 4 chiffres-n caractères.dat

suite à une erreur de manipulation, on désire remplacer toutes les années a par a - 1 (donc 2002 par 2001, 2003 par 2002, etc.). Si l'on suppose qu'une variable F prenne comme valeur le nom d'un de ces fichiers :

• 2002-ertyf.dat

alors on peut extraire l'année (2002) comme suit :

• annee=${F%-*}

maintenant la variable annee contient le nom du fichier sans ce qui se trouve à partir du caractère -. On peut alors décrémenter cette variable :

• annee=$((annee-1))

le nouveau nom du fichier sera composé de cette variable annee concaténée avec ce qui se trouve après le caractère -, soit :

• $annee-${F#*-}

D'où le script de conversion utilisant une boucle forLa structure for de bash

#!/bin/sh
for F in ????-*.dat ; do
  annee=${F%-*}
  annee=$((annee-1))
  mv "$F" $annee-${F#*-}
done

On aurait également pu extraire les deux parties du nom de fichier (année et le reste) à l'aide de sedsed comme le montre le programme suivant :

#!/bin/sh
for F in ????-*.dat ; do
  annee=$(echo "$F" | sed -r 's/([0-9]{4})-.*/\1/')
  reste=$(echo "$F" | sed -r 's/[0-9]{4}-(.*)/\1/')
  annee=$((annee-1))
  echo mv "$F" $annee-$reste
done

Pour information l'expression régulière :

[0-9]{4}-.*

reconnaîtra une chaîne de caractères commençant par 4 chiffres, suivis d'un tiret, suivi de ce qui vous passe par la tête. On notera également l'utilisation de la substitution de commandeSubstitution de commande et d'un tube pour stocker dans une variable l'application de la commande sed à la valeur $F. 

La syntaxe pour effectuer un test - que nous reprendrons plus loin avec les structures de contrôle - est la suivante :

• test expression_booléenne

ou

• [ expression_booléenne ]

Plusieurs tests sont disponibles, ayant trait au contrôle de caractéristiques de fichiers (existence, exécutabilité, etc.) et à la comparaison de chaine de caractères, ou d'expressions arithmétiques. Parmi celles-ci :

Les expressions booléennes effectuant des tests arithmétiques peuvent quant à elles, être réalisées sous la forme :

• expr₁ opérateur expr₂

où opérateur peut prendre les valeurs du tableau ci-dessous :

On peut également combiner les expressions booléennes :

Le shell - notamment bash - dispose de bien d'autres outils de tests et nous vous invitons vivement à compulser la page de manuel ou vous procurer l'ouvrage de Newham et Rosenblatt (1998) pour de plus amples informations. 

Voici trois structures de contrôle disponibles dans bash. Ce sont les trois structures classiques d'un langage de programmation :

• le « if then else » pour faire un choix à partir d'une expression booléenne ;
• le « case » permettant de faire un choix multiple en fonction d'une expression ;
• le « tant que » dont le but est de réitérer des commandes tant qu'une expression est vraie.

Le shell dispose de quelques autres structures que nous passerons sous silence. On peut également se référer au paragraphe 3.4.3La structure for de bash pour la structure de contrôle de type « for ». Toujours dans un souci de pragmatisme nous illustrons ici l'usage de ces trois structures de contrôle grâce à des exemples. Examinons tout d'abord le if :

#!/bin/sh
A=$1
B=$2
if [ $A -lt $B ]; then
  echo "l'argument 1 est plus petit que l'argument 2"
else
  echo "l'argument 1 est plus grand que l'argument 2"
fi

On peut noter l'utilisation du test […] et du mot-clef fi qui termine la clause if then else. Il ne faut pas omettre le point-virgule qui clôt l'expression test. À l'exécution :

$ ./testif.sh 4 6
l'argument 1 est plus petit que l'argument 2
$ ./testif.sh 45 6
l'argument 1 est plus grand que l'argument 2
$

Pour illustrer l'utilisation du while écrivons une petite boucle qui compte de 1 à n (un nombre donné par l'utilisateur) :

#!/bin/sh
LAST=$1
n=1
while [ "$n" -le "$LAST" ]; do
  echo -n "$n"
  n=$((n+1))
done
echo et voilou

qui donne par exemple :

$ ./testwhile.sh 10
1 2 3 4 5 6 7 8 9 10 et voilou
$

Notez le mot-clef done qui clôt la clause while. Ici l'option -n de la commande echo ne crée pas de saut de ligne à la fin de l'affichage. Histoire de confirmer l'assertion de Larry Wall(79), on peut utiliser une boucle « pour » pour générer et afficher une séquence. On fera appel à la commande seq dont voici un exemple d'utilisation :

$ seq 1 5
1
2
3
4
5
$

ce petit utilitaire a donc pour tâche d'afficher les entiers de 1 à 5. Si vous êtes curieux, la page de manuel vous indiquera que l'on peut également changer l'incrément et deux ou trois autres choses. On peut donc écrire le script suivant :

#!/bin/sh
for I in $(seq 1 10); do
  printf "%d " "$I"
done
echo et voilou.

qui donne le même résultat que le script précédent.

Les puristes auront noté que la commande seq n'est disponible que pour les utilisateurs travaillant sur des systèmes où le paquet coreutils de chez M. gnu est installé.

Pour ce qui est du case, on peut imaginer que l'on veuille écrire un script permettant d'identifier l'origine des fichiers en fonction de leur extension(80).

#!/bin/sh

NOM=${1:?"Donnez un nom de fichier svp"}
EXT=${NOM##*.}

case $EXT in
  tex) echo on dirait un fichier TeX ;;
  dvi) echo on dirait un fichier device independant ;;
  ps) echo on dirait un fichier Postscript ;;
  *) echo chai pô ;;
esac

On utilise ici le modificateur de variable ## pour supprimer la plus grande chaîne finissant par le caractère « . » et ainsi obtenir l'extension. Le mot-clef esac (case à l'envers) clôt la clause case. Le choix par défaut est indiqué par « * » (n'importe quelle chaîne de caractères). À chaque choix correspond une série de commandes à exécuter (ici une seule) ; série qui doit être terminée par deux points-virgules « ;; ».

On teste :

$ ./testcase-I.sh ~/LaTeX/guide/guide-unix.tex
on dirait un fichier TeX
$ ./testcase-I.sh /etc/lpd.conf
chai p^o
$

La chaîne de caractères précédant la parenthèse dans chaque clause de case peut être un jokerCaractères génériques (wildcard), comme le montre la dernière clause qui utilise le caractère * pour indiquer « toute (autre) chaîne de caractère ».

Une limitation du script précédent est que les fichiers :

tex
.tex

seront pris pour un fichier TEX. Ceci est dû au fait que si :

$ NOM=tex
$

alors l'expression ${NOM##*.} renvoie tex car aucune substitution n'a pu être réalisée.

On peut imaginer la solution suivante qui utilise les caractères génériques du shell :

#!/bin/bash
NOM=${1:?"Donnez un nom de fichier svp"}
case $NOM in
  *[^/].tex) echo on dirait un fichier TeX ;;
  *[^/].dvi) echo on dirait un fichier device independant ;;
  *[^/].ps) echo on dirait un fichier Postscript ;;
  *) echo chai pô ;;
esac

Dans ce script, l'expression *[^/].tex veut dire toute chaîne de caractères composée de :

• * : toute chaîne même vide ;
• [^/] : un caractère différent de / ;
• .tex

Les expressions booléennes utilisées par exemple dans la structure if sont en réalité la valeur de retour d'une commande. En effet toute commande unix renvoie une valeur en fonction du succès de son exécution. Il existe en outre une variable particulière contenant le code retour de la dernière commande exécutée : la variable $?. Voici un exemple avec la commande id qui donne des informations sur un utilisateur particulier :

$ id lozano
uid=1135(lozano) gid=200(users) groups=200(users)
$ echo $?
0  <------------------------------------------ tout s'est bien passé.
$ id djobi
id: djobi: No such user
$ id $?
1  <------------------------------------------ Il y a eu un problème.
$

On peut alors utiliser cette valeur directement dans une structure de type if comme suit :

#!/bin/bash
if id $1 2> /dev/null 1>&2; then
  echo c\'est un utilisateur
else
  echo ce n\'est pas un utilisateur
fi

Il est important de noter que dans la construction :

• if commande test ; then
      commandes
  fi

commandes seront exécutées si et seulement si commande test renvoie la valeur 0 (indépendamment de ce qu'elle peut afficher). Dans notre exemple on a donc :

$ ./testtest.sh lozano

c'est un utilisateur

$ ./testtest.sh djobi
ce n'est pas un utilisateur
$

On peut noter l'utilisation de redirectionsRedirections et tubes 2> pour rediriger le flux d'erreur (2) et 1>&2 pour rediriger le flux de sortie (1) sur le flux d'erreur (2).

Un script renvoie la valeur retournée par la dernière commande exécutée. On peut cependant forcer le renvoi d'une valeur particulière en utilisant la commande exit suivie d'une valeur.

Pour finir ce paragraphe et boucler la boucle des « expressions booléennes », supposons qu'il existe dans le répertoire courant un fichier guide-unix.tex et tapons :

$ [ -f guide-unix.tex ]
$ echo $?
0  <----------------------------------------------- le fichier existe
$
Puis :
$ [ -f guide-unix.texitoi ]
$ echo $?
1  <-------------------------------------- le fichier n'existe de pas
$

Où l'on apprend donc que [ est une commande qui, comme beaucoup de ses copines, renvoie 0 si tout est ok, et 1 sinon… 

Comme nous le notions un peu plus haut, make permet de fabriquer des fichiers. Le fichier que l'on veut construire s'appelle en jargon make, la cible. Supposons que le fichier à exporter s'appelle test.fig, le fichier à fabriquer se nommera test.eps. On crée alors un fichier que l'on nomme Makefile contenant :

test.eps :

↦ fig2dev -L eps test.fig > test.eps

le caractère ↦ indique l'insertion d'une tabulation. Sa présence est indispensable pour que l'utilitaire make analyse les règles du fichier makefile.

Par défaut, make cherche à exécuter la première cible qu'il rencontre. Par convention, on définit une cible all pour « tout faire » :

all : test.eps

test.eps :
↦ fig2dev -L eps test.fig > test.eps

Pour construire le fichier test.eps on peut alors au choix lancer :

$ make
fig2dev -L eps test.fig > test.eps
$

ou :

$ make test.eps
fig2dev -L eps test.fig > test.eps
$

On peut d'ores et déjà remarquer que la commande à exécuter est préalablement affichée à l'écran ; ceci peut être désactivé (voir 5.3.5Options et fonctionnalités diverses). 

À chaque modification du fichier test.fig, il est nécessaire d'exporter à nouveau en eps. C'est typiquement le genre de tâche que l'on peut confier à make. On insère donc dans le fichier Makefile une dépendance qui spécifie que la construction du fichier test.eps dépend de la date du fichier test.fig :

test.eps : test.fig
↦ fig2dev -L eps test.fig > test.eps

La signification de cette dépendance est la suivante :

1. si le fichier test.fig est plus récent que le fichier test.eps la prochaine invocation de make construira à nouveau test.eps ;
2. sinon une invocation de make donnera :

$ make
make: `test.eps' is up to date.
$

qui est tout simplement la traduction de « est à jour ».

L'utilitaire make gère les dépendances en utilisant les dates associées aux fichiers ; il est donc impératif que l'horloge du système fonctionne correctement et en particulier, dans le cas d'un système en réseau, que l'heure du système stockant les fichiers soit synchrone avec l'heure du système exécutant l'utilitaire lui-même.

L'ensemble formé par une cible, une ou des dépendances, et les commandes s'appelle une règle. La syntaxe générale est la suivante :

• cible : dépendances
  ↦ commande1
  ↦ commande2
  ↦ …
  ↦ commande_n

Nous verrons par la suite que l'on peut définir des règles relativement subtiles permettant d'automatiser la gestion de fichiers de projets complexes.

Comme toute commande unix, make peut prendre quelques options et paramètres :

• les paramètres doivent correspondre au nom d'une cible du Makefile. Dans notre exemple, elle peut être :

   

  Sélectionnez

  $ make bidule.eps
  ...
  $

  ou :

   

  Sélectionnez

  $ make clean
  rm -f arborescence.eps disques.eps flux.eps pipes.eps
  $

  si le fichier bidule.fig existe. Si make ne trouve pas de règle pour fabriquer la cible, un message d'erreur est renvoyé :

   

  Sélectionnez

  $ make djobi
  make: Nothing to be done for `djobi'.
  $

  Si aucun paramètre n'est précisé, c'est la première cible rencontrée qui est exécutée.

• par défaut make cherche les règles et les cibles parmi quelques fichiers dont les noms sont prédéfinis (Makefile, makefile, etc.), l'option -f permet d'utiliser un autre nom pour le fichier :

   

  Sélectionnez

  $ make -f bidule.mak
  ...
  $

• l'option -n demande à make d'afficher les commandes prévues pour la cible en question, sans les exécuter ; ce qui peut être utile pour déboguer les Makefile ;

• notez enfin que si la commande d'une règle est préfixée par le caractère @, cette commande n'est pas affichée avant d'être exécutée comme elle l'est par défaut :

   

  Sélectionnez

  cible1 :
  ↦ echo six bleus 1
  cible2 :
  ↦ @echo six bleus 2

   

  Sélectionnez

  $ make cible1 cible2
  echo six bleus 1  <------------------------ echo de la commande
  six bleus 1
  six bleus 2  <-------------------------- pas d'echo pour cible2
  $

Comme nous aurons l'occasion de le voir au paragraphe 5.4Faire des projets en langage C les utilitaires make, et notamment le gnu make, définissent certaines règles dites implicites pour fabriquer des fichiers « standards ». À titre d'information, le gnu make dispose d'un catalogue de règles pour, entre autres :

• compiler du C, du C++, du Pascal ;
• faire des éditions de liens ;
• créer des fichiers dvi à partir des sources TEX;
• …

Nous exploiterons ces règles prédéfinies dans la section suivante dédiée à la compilation d'un programme en langage C.

On peut dans le cas simple d'un projet se réduisant à un seul fichier source, lancer une commande qui crée directement l'exécutable :

$ gcc -o simple simple.c
$

C'est l'option -o nom qui permet de créer un exécutable dont le nom est nom(86). Ce nom peut être choisi librement, aucune extension particulière n'est nécessaire. Ce sont les attributs du fichier qui le rendent exécutable et non son nom.

Ici les phases de compilation et d'édition de liens sont réalisées automatiquement sans que l'utilisateur n'ait à le demander explicitement. Dans ce cas, l'éditeur de liens trouve le code de la fonction f dans le fichier simple.c compilé.

On exécute le fichier résultant de l'édition de liens en l'appelant par son nom :

$ ./simple
Bonjour tout le monde.
$

Tant que le répertoire où réside l'exécutable n'est pas listé dans le contenu de la variable PATH, il est nécessaire de préfixer l'exécutable par le chemin pour pouvoir l'exécuter : c'est ici la signification du « ./ » dans ./test. Dans le cas contraire, deux cas peuvent se produire :

1. le système ne trouve pas votre programme, par exemple si votre programme s'appelle bidule et que vous tentez de l'exécuter comme suit :

    

   Sélectionnez

   $ bidule
   bash: bidule: command not found
   $

2. le système n'appelle pas votre programme. Par exemple si vous avez la mauvaise idée de nommer votre exécutable test :

$ test  <------------------------------ Il semble ne rien se passer
$ type test
test is a shell builtin
$

il existe donc une autre commande nommée test et c'est elle qui est exécutée à la place de la vôtre.

Certains objecteront à la lecture de ce paragraphe : « Mais pourquoi ne pas rajouter le répertoire courant dans la variable PATH(87) ? » La réponse est que pour des raisons de sécurité il n'est pas conseillé de rajouter « . » (le répertoire courant) dans cette variable (lire à ce sujet Garfinkel et Spafford (1996)). Il est donc bon de prendre d'ores et déjà l'habitude d'utiliser le fameux « ./ ». On pourra également lire le paragraphe 6.1.4Environnement de développement qui propose une autre solution. 

Avant d'être compilé, un source en langage C est passé à la moulinette du préprocesseur. Ce programme va traiter toutes les directives de type #… et les remplacer par du code source. Il supprimera également tous les commentaires. Le résultat de ce « traitement de texte » sera présenté au compilateur. Sous unix, le préprocesseur porte le doux nom de cpp (C preprocessor). On peut voir cpp en action en utilisant l'option -E de gcc, sur un fichier exemple :

#define N 4
#define carre(a) ((a)*(a))

int main(int argc, char** argv)
{
    int i=N,j,k;
    j=2*N;
    k=carre(i+j);
    return 0;
}

puis :

$ gcc -E testcpp.c
int main(int argc, char** argv)
{
    int i= 4 ,j,k;
    j=2* 4 ;
    k= (( i+j )*( i+j ));
    return 0;
}
$

On peut également noter que le préprocesseur de gcc définit plusieurs symboles qui identifient le système sous-jacent. On peut utiliser ces symboles lorsqu'on veut créer du code C portable d'un système (unix) à un autre :

$ cpp -dM testcpp.c
...
#define __linux__ 1
#define __gnu_linux__ 1
#define __unix__ 1
#define __i386__ 1
#define __INT_MAX__ 2147483647
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __DBL_MIN__ 2.2250738585072014e-308
#define N 4
$

Ces symboles peuvent ensuite être exploités par des directives de type #ifdef :

#if defined __linux__ && defined __i386__
  int fonction_de_la_mort(int,int)
#else
  int fonction_de_la_mort(double,double)
#endif

Lorsque cpp se met en branle, et qu'il rencontre une directive #include, il va chercher dans une liste de répertoires le fichier spécifié. On peut voir la liste de recherche par défaut en utilisant à nouveau l'option -v de gcc :

$ gcc -v -E fantome.c
...
gcc version 3.3.5 (Debian 1:3.3.5-13)
/usr/lib/gcc-lib/i486-linux/3.3.5/cc1 -E -quiet -v src/testcpp.c
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/i386-redhat-linux/include
/usr/lib/gcc-lib/i486-linux/3.3.5/include
/usr/include
End of search list.
$

On notera que :

• les fichiers inclus par une directive du type #include "fichier" sont recherchés à partir du répertoire courant ;

• on peut influer sur la liste des répertoires dans lesquels une directive #include recherche les fichiers, grâce à l'option -I de gcc. Si par exemple, on désire inclure le fichier bidule.h se trouvant dans ~/mes_includes, on spécifiera en ligne de commande :

   

  Sélectionnez

  $ gcc -I ~/mes_includes -c monfichier.c

• avec :

  monfichier.c

  Sélectionnez

  #include <bidule.h> /* ou "bidule.h" */
  ...

Sur les systèmes unix utilisant l'environnement de développement de chez gnu, la plupart des langages de programmation compilés (C, C++, Pascal, Prolog) sont d'abord traduits en langage d'assemblage, on fait ensuite appel à l'outil assembleur pour produire le fichier objet. Par simple curiosité on peut voir le code assembleur produit pour le fichier suivant :

int mafonction(double d)
{
    return 2.3*d-7.4;
}

On peut demander à gcc de s'arrêter à la phase d'assemblage (c'est-à-dire ne pas produire le fichier objet) avec la commande suivante :

$ gcc -S testas.c
$ ls -l testas.*
-rw-r--r-- 1 lozano lozano 57 Nov 11 18:30 testas.c
-rw-r--r-- 1 lozano lozano 640 Nov 11 18:31 testas.s
$

On peut alors - toujours dans le cadre d'une curiosité malsaine - examiner le contenant du code assembleur généré, avec la commande cat :

$ cat testas.s
...
mafonction:
pushl ?p
movl %esp, ?p
subl $16, %esp
...
$

On peut ensuite traduire ce code en appelant explicitement l'outil assembleur :

$ as testas.s -o testas.o
$

gcc dispose de moult options que nous ne détaillerons bien évidemment pas ici.

Voici cependant quelques options utiles à connaître pour mener à bien vos projets :

• l'option -Onombre (88) met en route différentes méthodes d'optimisation pour produire du code plus rapide ou utilisant moins de mémoire. En ce qui concerne nombre, il peut prendre des valeurs de 0 à 3 (0 : pas d'optimisation, 3 : optimisation max) ;
• l'option -Wall affiche tous les warnings de compilation ; c'est une option incontournable qui permet d'attirer l'attention du programmeur sur des portions de programmes « douteuses » (variables non initialisées, problème de transtypage…) ;
• -Dmacro est une option passée au préprocesseur qui produit le même résultat que l'inclusion dans le source d'une ligne #define macro 1 ;

Pour créer un fichier objet à partir d'une source en langage C - c'est-à-dire procéder à la phase de compilation - on peut lancer la commande :

$ gcc -c main.c -o main.o  <------------- compilation du premier module
$ gcc -c mod.c -o mod.o  <-------------- compilation du deuxième module
$

Il faut noter ici l'option -c du compilateur qui précise qu'on n'effectue que la compilation et l'option -o (output) précise que les fichiers objet doivent être stockés dans les fichiers main.o et mod.o.

Pour passer à la phase suivante qui est la création de l'exécutable par le biais de l'édition de liens, on utilise la commande suivante :

$ gcc -o main main.o mod.o
$

Pour effectuer l'édition de liens, on précise donc le nom de l'exécutable avec l'option -o, et on spécifie quels sont les fichiers objet à lier. 

Pour ce qui concerne Linux - et c'est le cas de la plupart des systèmes unix - les exécutables créés sont des exécutables dynamiques, c'est-à-dire que le code qu'ils contiennent fait appel à des bibliothèques dynamiques. Soit le source suivant :

#include <stdio.h>

int main()
{
    printf("bonjour tout le monde\n");
    return 0;
}

et la commande suivante pour créer un exécutable :

$ gcc -o bonjour bonjour.c
$

On peut examiner l'exécutable créé avec la commande ldd pour obtenir les bibliothèques dont il dépend :

$ ldd bonjour
libc.so.6 => /lib/libc.so.6 (0x4001a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$

On voit donc ici que l'exécutable bonjour est lié dynamiquement avec la bibliothèque standard, dite « libC » (voir figure 5.3). Ces deux bibliothèques sont automatiquement ajoutées à l'édition de liens, sur le système Linux de l'auteur. La première contient le code de la bibliothèque standard du C (et donc celui de la fonction printf), la deuxième contient les instructions permettant de charger dynamiquement les bibliothèques.

Dans certaines situations, il faut préciser explicitement que le code fait appel à des fonctions définies dans une bibliothèque spécifique. Par exemple pour compiler le fichier en langage C suivant faisant appel à une routine de la bibliothèque mathématique :

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main(int argc, char** argv)
{
    if (argc==2)
        /* renvoie la racine de l'argument 1 */
        printf("%f\n",sqrt(atof(argv[1])));
    return 0;
}

on procédera comme suit :

$ gcc -c testmath.c -o testmath.o
$ gcc -o testmath testmath.o -lm
$

L'option -l précise que l'on veut ajouter la bibliothèque mathématique du C à l'édition de liens. On a alors :

$ ldd testmath
libm.so.6 => /lib/libm.so.6 (0x40021000)
libc.so.6 => /lib/libc.so.6 (0x40043000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$

on constate donc que l'exécutable testmath est lié dynamiquement avec la bibliothèque mathématique stockée dans le fichier /lib/libm.so.6. Il est possible de forcer la création d'un exécutable statique. Pour cela on impose alors au linker d'insérer dans l'exécutable le code des fonctions provenant de ou des bibliothèques nécessaires :

$ gcc -static -o testmath.stat testmath.o -lm
$ ls -lh testmath*
-rwxr-xr-x 1 lozano lozano 12K Nov 11 17:54 testmath
-rw-r--r-- 1 lozano lozano 223 Nov 11 17:54 testmath.c
-rw-r--r-- 1 lozano lozano 948 Nov 11 17:54 testmath.o
-rwxr-xr-x 1 lozano lozano 471K Nov 11 17:58 testmath.stat
$

On pourra noter la différence de taille des exécutables créés. Ceci confirme que dans le cas « statique » le code des fonctions issu des bibliothèques est inséré dans l'exécutable (voir figure 5.4). 

Lorsqu'on précise, lors de l'édition de liens, l'option -l suivie de m, le linker cherche dans une série de répertoires prédéterminée, un fichier nommé libm.so pour la bibliothèque dynamique et libm.a pour la bibliothèque statique. Dans le cas où la bibliothèque à inclure n'est pas dans la liste de répertoires standard, il est nécessaire d'utiliser l'option -L suivie du répertoire où se trouve la bibliothèque en question. Par exemple, on écrira :

$ gcc -L ~/lib -o djobi djobi.o -lmabib
$

si la bibliothèque libmabib.so ou libmabib.a se trouve dans le répertoire ~/lib. S'il s'agit d'une bibliothèque dynamique (libmabib.so), pour pouvoir exécuter le fichier djobi, il faudra impérativement indiquer au programme qui charge les bibliothèques dynamiques où se trouve libmabib.so. On peut réaliser cela en positionnant la variable d'environnement LD_LIBRARY_PATH avec la liste des répertoires susceptibles de contenir des bibliothèques dynamiques :

export LD_LIBRARY_PATH=dir1 :dir2 : $LD_LIBRARY_PATH

Dans notre exemple on écrira :

$ export LD_LIBRARY_PATH=~/lib:$LD_LIBRARY_PATH
$

À titre indicatif, sous le système HPUX (l'unix de Hewlett Packard) cette variable se nomme SHLIB_PATH.

On peut créer des bibliothèques qui seront liées statiquement ou dynamiquement lors de l'édition de liens. La création d'une bibliothèque consiste à rassembler un certain nombre de fichiers objets dans un seul fichier. On supposera, à titre d'exemple, que l'on dispose de trois fichiers : mod1.o mod2.o et mod3.o résultant de la compilation de trois fichiers écrits en langage C.

Statique - Pour créer une bibliothèque statique, on pourra utiliser la commande :

$ ar ruv libbidule.a mod1.o mod2.o mod3.o
ar: creation de libbidule.a
a - mod1.o
a - mod2.o
a - mod3.o
$

La commande ar crée un fichier bibliothèque libbidule.a. L'option ru permet d'insérer en remplaçant chaque objet dans l'archive, l'option v permet de rendre la commande ar plus bavarde qu'elle ne l'est par défaut. On se reportera à la page de manuel pour plus de détail. Une fois la bibliothèque statique créée on peut l'utiliser lors d'une édition de liens comme suit :

$ gcc -L. -o monappli monmain.o -lbidule
$

On notera :

1. l'option -L pour indiquer qu'il faut chercher la bibliothèque dans le répertoire courant ;
2. la syntaxe -lbidule qui cherche une bibliothèque nommée libbidule.a

L'option -s de la commande ar ou l'utilisation de la commande ranlib en lieu et place de ar permet de créer un index des symboles et ainsi d'accélérer les éditions de liens que l'on réalisera avec la bibliothèque.

Dynamique - Pour créer une bibliothèque dynamique on utilisera la syntaxe suivante :

$ gcc -shared -o libbidule.so mod1.o mod2.o mod3.o
$

Pour utiliser une telle bibliothèque à l'édition de liens :

$ gcc -L. -o monappli monmain.o -lbidule
$

Il faudra s'assurer que la variable d'environnement LD_LIBRARY_PATH contienne le répertoire où se trouve libbidule.so pour que cette dernière puisse être chargée au moment de l'exécution de monappli (cf. § 5.4.4Bibliothèques).