Chapitre 12. Programmation

Table des matières

12.1. Les scripts de l’interpréteur de commande
12.1.1. Compatibilité de l’interpréteur de commandes avec POSIX
12.1.2. Paramètres de l’interpréteur de commandes
12.1.3. Opérateurs conditionnels de l’interpréteur
12.1.4. Boucles de l’interpréteur de commandes
12.1.5. Shell environment variables
12.1.6. Séquence de traitement de la ligne de commandes de l’interpréteur
12.1.7. Programmes utilitaires pour les scripts de l’interpréteur de commandes
12.2. Scripting in interpreted languages
12.2.1. Debugging interpreted language codes
12.2.2. GUI program with the shell script
12.2.3. Custom actions for GUI filer
12.2.4. Folie de courts scripts en Perl
12.3. Coding in compiled languages
12.3.1. C
12.3.2. Programme simple en C (gcc)
12.3.3. Flex -- un meilleur Lex
12.3.4. Bison -- un meilleur Yacc
12.4. Outils d’analyse du code statique
12.5. Déboguer
12.5.1. Exécution de base de gdb
12.5.2. Déboguer un paquet Debian
12.5.3. Obtenir une trace
12.5.4. Commandes avancées de gdb
12.5.5. Vérifier les dépendances avec les bibliothèques
12.5.6. Dynamic call tracing tools
12.5.7. Déboguer les erreurs de X
12.5.8. Outils de détection des fuites de mémoire
12.5.9. Désassembler un binaire
12.6. Build tools
12.6.1. Make
12.6.2. Autotools
12.6.2.1. Compiler et installer un programme
12.6.2.2. Désinstaller un programme
12.6.3. Meson
12.7. Web
12.8. La conversion du code source
12.9. Créer un paquet Debian

Je donne quelques indications pour apprendre à programmer sous le système Debian, suffisantes pour suivre le code source mis en paquets. Voici les paquets importants correspondant aux paquets de documentation pour la programmation .

Une référence en ligne est accessible en entrant « man name » après l’installation des paquets manpages et manpages-dev. Les références en ligne des outils GNU tools sont disponibles en entrant « info nom_programme » après l’installation des paquets de documentation pertinents. Vous devrez peut-être inclure les archives contrib et non-free en plus de l’archive main car certaines documentations GFDL ne sont pas considérées comme conformes à DFSG.

Please consider to use version control system tools. See Section 10.5, « Git ».

[Avertissement] Avertissement

N’utilisez pas « test » comme nom d’un fichier exécutable. « test » fait partie de l’interpréteur de commandes.

[Attention] Attention

Vous devrez installer les programmes directement compilés à partir des sources dans « /usr/local » ou « /opt » afin d’éviter des collisions avec les programmes du système.

[Astuce] Astuce

Les exemples de code pour la création de « Song 99 Bottles of Beer » devraient vous donner de bonnes indications sur pratiquement tous les langages de programmation.

Le script de l’interpréteur de commandes (« shell script » est un fichier texte dont le bit d’exécution est positionné et qui contient des commandes dans le format suivant :

#!/bin/sh
 ... command lines

La première ligne indique l’interpréteur qui sera utilisé pour lire et exécuter le contenu de ce fichier.

La lecture des scripts de l’interpréteur de commandes est la meilleure manière de comprendre comment fonctionne un système de type UNIX. Je donne ici quelques indications et rappels de la programmation avec l’interpréteur de commandes. Consultez « Erreurs en shell » (http://www.greenend.org.uk/rjk/2001/04/shell.html) pour apprendre à partir d’erreurs.

Contrairement à l’interpréteur de commandes en mode interactif (consultez Section 1.5, « La commande simple de l’interpréteur de commandes » et Section 1.6, « Traitement des données textuelles à la UNIX »), les scripts de l’interpréteur de commandes utilisent souvent des paramètres, des conditions et des boucles.

Many system scripts may be interpreted by any one of POSIX shells (see Tableau 1.13, « Liste d’interpréteurs de commandes (« shells ») »).

  • The default non-interactive POSIX shell "/bin/sh" is a symlink pointing to /usr/bin/dash and used by many system programs.

  • The default interactive POSIX shell is /usr/bin/bash.

Évitez d’écrire des scripts de l’interpréteur de commandes avec des bashismes ou des zshismes afin de les rendre portables entre tous les interpréteurs POSIX. Vous pouvez le vérifier en utilisant checkbashisms(1).


La commande « echo » doit être utilisée avec les précautions suivantes car son implémentation diffère selon que l’on utilise les commandes internes ou externes de l’interpréteur de commandes :

  • Éviter d’utiliser toutes les options de commandes sauf « -n ».

  • Éviter d’utiliser les séquences d’échappement dans les chaînes de caractères car leur prise en compte varie.

[Note] Note

Bien que l’option « -n » ne soit pas vraiment de la syntaxe POSIX, elle est généralement acceptée.

[Astuce] Astuce

Utilisez la commande « printf » plutôt que la commande « echo » si vous avez besoin d’intégrer des séquences d’échappement dans la chaîne de sortie.

Des paramètres spéciaux de l’interpréteur de commandes sont souvent utilisés dans les scripts de l’interpréteur de commandes.


Les expansions de paramètre les plus courantes à retenir sont mentionnées ci-dessous :


Ici, les deux points « : » dans tous ces opérateurs sont en fait optionnels.

  • avec « : » = opérateur de test pour existe et différent de null

  • sans « : » = opérateur de test pour existe uniquement


Chaque commande retourne un état de sortie qui peut être utilisé pour des expressions conditionnelles.

  • Succès : 0 (« Vrai »)

  • Erreur : différent de 0 (« Faux »)

[Note] Note

« 0 » dans le contexte conditionnel de l’interpréteur signifie « Vrai » alors que « 0 » dans le contexte conditionnel de C signifie « Faux ».

[Note] Note

« [ » est l’équivalent de la commande test, qui évalue, comme expression conditionnelle, les paramètres jusqu’à « ] ».

Les idiomes conditionnels de base à retenir sont les suivants :

  • « commande && si_succès_lancer_aussi_cette_commande || true »

  • « commande || en_cas_de_non_succès_lancer_aussi_cette_commande || true »

  • Un morceau de script sur plusieurs lignes comme le suivant :

if [ conditional_expression ]; then
 if_success_run_this_command
else
 if_not_success_run_this_command
fi

Ici, le « || true » était nécessaire pour s’assurer que ce script de l’interpréteur ne se termine pas accidentellement à cette ligne lorsque l’interpréteur est appelé avec l’indicateur « -e ».



Les opérateurs de comparaison arithmétique entière dans les expressions conditionnelles sont « -eq », « -ne », « -lt », « -le », « -gt » et « -ge ».

En gros, l’interpréteur de commandes traite un script de la manière suivante :

  • l’interpréteur de commandes lit une ligne :

  • l’interpréteur de commandes regroupe une partie de la ligne sous forme d’un élément (« token » si elle se trouve entre "…" ou '…' :

  • l’interpréteur de commandes découpe les autres parties de la ligne en éléments comme suit :

    • Espaces : espace tabulation saut-de-ligne

    • Metacharacters: | ; & ( )

  • l’interpréteur de commandes vérifie les mots réservés pour chacun des éléments et ajuste son comportement s’il ne se trouve pas entre "…" ou '…'.

    • mot réservé : if then elif else fi for in while unless do done case esac

  • L’interpréteur de commandes étend les alias s’ils ne se trouvent pas entre "…" ou '…'.

  • l’interpréteur de commandes étend les tilde s’ils ne se trouvent pas entre "…" ou '…'.

    • « ~ » → répertoire personnel de l’utilisateur actuel

    • « ~utilisateur » → répertoire personnel de l’utilisateur

  • l’interpréteur de commandes étend les paramètres en leur valeur s’ils ne sont pas entre '…'.

    • paramètre : « $PARAMETRE » ou « ${PARAMETRE} »

  • l’interpréteur de commandes étend la substitution de commande si elle n’est pas entre '…'.

    • « $( commande ) » → sortie de la « commande »

    • « ` commande ` » → sortie de la « commande »

  • l’interpréteur de commandes étend les motifs génériques du chemin aux fichiers correspondants s’ils ne sont pas entre  "…" ou '…'.

    • * → n’importe quel caractère

    • ? → un caractère

    • […] → un caractère quelconque parmi «  »

  • l’interpréteur de commandes recherche la commande dans ce qui suit et l’exécute.

    • définition de fonction

    • commande interne (« builtin »)

    • fichier exécutable dans « $PATH »

  • l’interpréteur de commandes passe à la ligne suivante et recommence ce traitement depuis le début de la séquence.

Des guillemets simples dans des guillemets doubles n’ont pas d’effet.

Exécuter « set -x » dans le script de l’interpréteur ou l’appel du script avec l’option « -x » fait imprimer par l’interpréteur de commandes toutes les commandes exécutées. C’est assez pratique pour le débogage.


When you wish to automate a task on Debian, you should script it with an interpreted language first. The guide line for the choice of the interpreted language is:

  • Use dash, if the task is a simple one which combines CLI programs with a shell program.

  • Use python3, if the task isn't a simple one and you are writing it from scratch.

  • Use perl, tcl, ruby, ... if there is an existing code using one of these languages on Debian which needs to be touched up to do the task.

If the resulting code is too slow, you can rewrite only the critical portion for the execution speed in a compiled language and call it from the interpreted language.

The shell script can be improved to create an attractive GUI program. The trick is to use one of so-called dialog programs instead of dull interaction using echo and read commands.


Here is an example of GUI program to demonstrate how easy it is just with a shell script.

This script uses zenity to select a file (default /etc/motd) and display it.

GUI launcher for this script can be created following Section 9.4.10, « Lancer un programme depuis l’interface graphique ».

#!/bin/sh -e
# Copyright (C) 2021 Osamu Aoki <osamu@debian.org>, Public Domain
# vim:set sw=2 sts=2 et:
DATA_FILE=$(zenity --file-selection --filename="/etc/motd" --title="Select a file to check") || \
  ( echo "E: File selection error" >&2 ; exit 1 )
# Check size of archive
if ( file -ib "$DATA_FILE" | grep -qe '^text/' ) ; then
  zenity --info --title="Check file: $DATA_FILE" --width 640  --height 400 \
    --text="$(head -n 20 "$DATA_FILE")"
else
  zenity --info --title="Check file: $DATA_FILE" --width 640  --height 400 \
    --text="The data is MIME=$(file -ib "$DATA_FILE")"
fi

This kind of approach to GUI program with the shell script is useful only for simple choice cases. If you are to write any program with complexities, please consider writing it on more capable platform.


Here, Section 12.3.3, « Flex -- un meilleur Lex » and Section 12.3.4, « Bison -- un meilleur Yacc » are included to indicate how compiler-like program can be written in C language by compiling higher level description into C language.

Vous pouvez définir un environnement propre pour compiler des programmes écrits dans le langage de programmation C par ce qui suit :

# apt-get install glibc-doc manpages-dev libc6-dev gcc build-essential

Le paquet libc6-dev, c’est-à-dire la bibliothèque GNU C, fournit la bibliothèque C standard qui est une collection de fichiers d’en-têtes et de routines de bibliothèque utilisée par le langage de programmation C.

Consultez les références pour C comme suit; :

  • « info libc » (références des fonctions de la bibliothèque C)

  • gcc(1) et « info gcc »

  • chaque_nom_de_fonction_de la_bibliothèque_C(3)

  • Kernighan & Ritchie, « Le langage de programmation C », 2ème édition (Prentice Hall)

Flex est un générateur d’analyse lexicale rapide compatible avec Lex.

On trouve un didacticiel de flex(1) dans « info flex ».

Vous devez fournir vos propres « main() » et « yywrap() ». Sinon votre programme flex devrait ressembler à ce qui suit pour se compiler sans bibliothèque (cela parce que « yywrap » est une macro et que « %option main » active de manière implicite « %option noyywrap ».

%option main
%%
.|\n    ECHO ;
%%

Sinon, vous pouvez compiler avec l’option de l’éditeur de liens « -lfl » à la fin de la ligne de commandes de cc(1) (comme AT&T-Lex avec « -ll »). L’option « %option » n’est pas nécessaire dans ce cas.

Lint like tools can help automatic static code analysis.

Indent like tools can help human code reviews by reformatting source codes consistently.

Ctags like tools can help human code reviews by generating an index (or tag) file of names found in source codes.

[Astuce] Astuce

Configuring your favorite editor (emacs or vim) to use asynchronous lint engine plugins helps your code writing. These plugins are getting very powerful by taking advantage of Language Server Protocol. Since they are moving fast, using their upstream code instead of Debian package may be a good option.


Debug is important part of programming activities. Knowing how to debug programs makes you a good Debian user who can produce meaningful bug reports.


Le debogueur primaire sous Debian est gdb(1), il vous permet d’inspecter un programme alors qu’il tourne.

Installons gdb et les programmes associés par ce qui suit :

# apt-get install gdb gdb-doc build-essential devscripts

Good tutorial of gdb can be found:

  • info gdb

  • “Debugging with GDB” in /usr/share/doc/gdb-doc/html/gdb/index.html

  • tutorial on the web

Here is a simple example of using gdb(1) on a "program" compiled with the "-g" option to produce debugging information.

$ gdb program
(gdb) b 1                # set break point at line 1
(gdb) run args           # run program with args
(gdb) next               # next line
...
(gdb) step               # step forward
...
(gdb) p parm             # print parm
...
(gdb) p parm=12          # set value to 12
...
(gdb) quit
[Astuce] Astuce

De nombreuses commandes de gdb(1) possèdent une abréviation. L’expansion à l’aide de la touche de tabulation fonctionne comme avec l’interpréteur de commandes.

Since all installed binaries should be stripped on the Debian system by default, most debugging symbols are removed in the normal package. In order to debug Debian packages with gdb(1), *-dbgsym packages need to be installed (e.g. coreutils-dbgsym in the case of coreutils). The source packages generate *-dbgsym packages automatically along with normal binary packages and those debug packages are placed separately in debian-debug archive. Please refer to articles on Debian Wiki for more information.

If a package to be debugged does not provide its *-dbgsym package, you need to install it after rebuilding it by the following.

$ mkdir /path/new ; cd /path/new
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt-get install fakeroot devscripts build-essential
$ apt-get source package_name
$ cd package_name*
$ sudo apt-get build-dep ./

Corriger les bogues si nécessaire.

Modifier la version du paquet pour ne pas entrer en collision avec les versions officielles de Debian, par exemple, en ajoutant « +debug1 » pour la compilation d’une version de paquet existante, ou « ~pre1 » pour la compilation d’une version de paquet qui n’est pas encore diffusée de la manière suivante :

$ dch -i

Compiler et installer les paquets avec les symboles de débogage comme suit :

$ export DEB_BUILD_OPTIONS="nostrip noopt"
$ debuild
$ cd ..
$ sudo debi package_name*.changes

Vous devrez vérifier les scripts de construction du paquet et vous assurer que les options « CFLAGS=-g -Wall » sont positionnées pour la compilation des binaires.

Si vous rencontrez un plantage de programme, signaler le bogue avec un copier-coller des informations de trace est une bonne idée.

The backtrace can be obtained by gdb(1) using one of the following approaches:

For infinite loop or frozen keyboard situation, you can force to crash the program by pressing Ctrl-\ or Ctrl-C or executing “kill -ABRT PID”. (See Section 9.4.12, « Tuer un processus »)

[Astuce] Astuce

Souvent, vous voyez une trace où une ou plusieurs des lignes de départ se trouvent dans « malloc() » ou « g_malloc() ». Lorsque cela arrive, il y a des chances pour que votre trace ne soit pas très utile. La meilleure façon de trouver des informations utiles est de définir la variable d’environnement « $MALLOC_CHECK_ » à la valeur 2 (malloc(3)). Vous pouvez le faire en lançant gdb de la manière suivante :

 $ MALLOC_CHECK_=2 gdb hello

Make est un utilitaire destiné à la maintenance d’un groupe de programmes. Lors de l’exécution de make(1), make lit le fichier de règles, « Makefile » et met à jour une cible si elle dépend de fichiers qui ont été modifiés depuis que la cible a été modifiée pour la dernière fois ou si la cible n’existe pas. L’exécution de ces mises à jour peut être faite simultanément.

La syntaxe du fichier de règles est la suivante :

target: [ prerequisites ... ]
 [TAB]  command1
 [TAB]  -command2 # ignore errors
 [TAB]  @command3 # suppress echoing

Ici, « [TAB] » est un code de tabulation. Chaque ligne est interprétée par l’interpréteur de commandes après que make ait effectué la substitution des variables. Utilisez « \ » à la fin d’une ligne pour poursuivre le script. Utilisez « $$ » pour entrer un « $ » pour les valeurs des variables d’environnement d’un script de l’interpréteur de commandes.

On peut écrire des règles implicites pour la cible et les prérequis, par exemple, de la manière suivante :

%.o: %.c header.h

Ici, la cible contient le caractère « % » (exactement 1 caractère). Le caractère « % » peut correspondre à n’importe quelle sous-chaîne non vide des noms de fichiers de la cible actuelle. De même pour les prérequis, utilisez « % » pour afficher la manière dont leur nom est en relation avec le nom de la cible actuelle.



Exécutez « make -p -f/dev/null » afin de voir les règles automatiques internes.

Autotools is a suite of programming tools designed to assist in making source code packages portable to many Unix-like systems.

  • Autoconf is a tool to produce a shell script "configure" from "configure.ac".

    • "configure" is used later to produce "Makefile" from "Makefile.in" template.

  • Automake is a tool to produce "Makefile.in" from "Makefile.am".

  • Libtool is a shell script to address the software portability problem when compiling shared libraries from source code.

The software build system has been evolving:

  • Autotools on the top of Make has been the de facto standard for the portable build infrastructure since 1990s. This is extremely slow.

  • CMake initially released in 2000 improved speed significantly but was still build on the top of inherently slow Make.

  • Ninja initially released in 2012 is meant to replace Make for the further improved build speed but is also designed to have its input files generated by a higher-level build system.

  • Meson initially released in 2013 is the new popular and fast higher-level build system which uses Ninja as its backend.

See documents found at "The Meson Build system" and "The Ninja build system".

Des pages web dynamiques et interactives simples peuvent être faites de la manière suivante :

  • Les requêtes sont présentées au navigateur de l’utilisateur en utilisant des formulaires HTML.

  • Remplir et cliquer sur les entrées de formulaires envoie une des chaînes d’URL suivantes avec des paramètres codés depuis le navigateur vers le serveur web.

    • « http://www.foo.dom/cgi-bin/programme.pl?VAR1=VAL1&VAR2=VAL2&VAR3=VAL3 »

    • « http://www.foo.dom/cgi-bin/programme.py?VAR1=VAL1&VAR2=VAL2&VAR3=VAL3 »

    • « http://www.foo.dom/programme.php?VAR1=VAL1&VAR2=VAL2&VAR3=VAL3 »

  • « %nn » dans l’URL est remplacé par le caractère dont la valeur hexadécimale est nn.

  • La variable d’environnement est définie à : « QUERY_STRING="VAR1=VAL1 VAR2=VAL2 VAR3=VAL3" ».

  • Le programme CGI (l’un quelconque des « programme.* ») sur le serveur web s’exécute lui-même avec la variable d’environnement « $QUERY_STRING ».

  • La sortie standard (stdout) du programme CGI est envoyée au navigateur web et présentée sous forme d’une page web dynamique interactive.

Pour des raisons de sécurité, il est préférable de ne pas réaliser soi-même de nouvelles bidouilles pour analyser les paramètres CGI. Il existe des modules bien établis pour cela, en Perl et Python. PHP est fourni avec ces fonctionnalités. Lorsqu’il est nécessaire d’enregistrer des données du client, on utilise des cookies HTTP. Lorsqu’un traitement de données est nécessaire côté client, on utilise fréquemment Javascript.

Pour davantage d’informations, consultez Common Gateway Interface, The Apache Software Foundation et JavaScript.

Rechercher « CGI tutorial » sur Google en entrant l’URL encodée http://www.google.com/search?hl=en&ie=UTF-8&q=CGI+tutorial directement dans la barre d’adresse du navigateur est une bonne méthode pour voir un script CGI en action sur le serveur Google.

Il existe des programmes pour convertir les codes sources.


Si vous désirez créer un paquet Debian, lisez ce qui suit :

Il existe des paquets tels que debmake, dh-make, dh-make-perl, etc., qui facilitent la réalisation des paquets.