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. Variables d’environnement de l’interpréteur de commandes
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. Scriptage avec des langages interprétés
12.2.1. Débogage du code d’un langage interprété
12.2.2. Programmes graphiques avec des scripts de d’interpréteur de commandes
12.2.3. Actions personnalisées pour le gestionnaire de fichiers graphique
12.2.4. Extravagances des scripts courts en Perl
12.3. Codage dans les langages compilés
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. Outils de traçage dynamique des appels
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. Outils de construction
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.

Veuillez envisager d’utiliser des outils ds système de gestion de versions. Consulter la 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 » (https://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.

De nombreux scripts système peuvent être interprétés par l'un des interpréteurs de commandes POSIX (consulter le Tableau 1.13, « Liste d’interpréteurs de commandes (« shells ») »).

  • L'interpréteur de commandes POSIX par défaut non interactif « /usr/bin/sh » est un lien symbolique pointant vers /usr/bin/dash et est utilisé par de nombreux programmes du système.

  • L’interpréteur POSIX interactif par défaut est /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

    • métacaractères : < > | ; & ( )

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

De façon à rendre vos programmes de l’interpréteur de commandes aussi portables que possible dans tous les systèmes Debian, c’est une bonne idée de limiter les programmes utilitaires à ceux fournis par les paquets essentiels.

  • « aptitude search ~E » affiche la liste des essentiels.

  • « dpkg -L nom_paquet |grep '/man/man.*/' » affiche la liste des pages de manuel pour les commandes que fournit le paquet nom_paquet.


[Astuce] Astuce

Bien que moreutils puisse ne pas exister en dehors de Debian, il propose d’intéressants petits programmes. Le plus remarquable est sponge(8) qui est bien pratique pour écraser le fichier d’origine.

Consulter la Section 1.6, « Traitement des données textuelles à la UNIX » pour des exemples.


Lorsque vous souhaitez automatiser une tâche sur Debian, vous devez d’abord la scripter avec un langage interprété. La ligne directrice pour le choix de la langue interprétée est la suivante :

  • utilisez dash, si c’est une tâche simple qui combine des programmes en ligne de commandes avec un interpréteur ;

  • utilisez python3, si la tâche n’est pas simple et que vous l’écrivez à partir de zéro ;

  • utilisez perl, tcl, ruby..., s'il existe un code existant utilisant l'un de ces langages sur Debian et qui doit être retouché pour effectuer cette tâche.

Si le code résultant est trop lent, vous pouvez réécrire uniquement la partie critique pour la vitesse d'exécution dans un langage compilé et l'appeler depuis le langage interprété.

Le script d’interpréteur peut être amélioré pour créer un programme graphique attrayant. L’astuce consiste à utiliser l’un des programmes dits de dialogue au lieu d’une interaction insipide utilisant les commandes echo et read.


Voici un exemple de programme graphique pour démontrer à quel point c’est facile avec un script d’interpréteur.

Ce script utilise zenity pour sélectionner un fichier (par défaut /etc/motd) et l'afficher.

Le lanceur graphique pour ce script peut être créé en suivant la 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

Ce type d’approche du programme graphique avec un script d’interpréteur n’est utile que dans le cas de choix simple. Si vous devez écrire un programme avec des complexités, veuillez envisager de l’écrire à partir d’une plateforme plus adaptée.


Ici, la Section 12.3.3, « Flex -- un meilleur Lex » et la Section 12.3.4, « Bison -- un meilleur Yacc » sont incluses pour indiquer comment un programme de type compilateur peut être écrit en langage C en compilant une description de niveau supérieur en langage C.

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

Plusieurs exemples simples sont disponibles dans « /usr/share/doc/flex/examples/ ». [7]

Un certain nombre de paquets fournissent un analyseur LR à lecture anticipée (« lookahead ») compatible avec Yacc ou un générateur d’analyseur LALR sous Debian.


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

Vous devez fournir vos propre « main() » et « yyerror() ». « main() » appelle « yyparse() » qui appelle « yylex() », habituellement créé avec Flex.

Voici un exemple de création de programme de calcul dans un terminal.

Créons example.y :

/* calculator source for bison */
%{
#include <stdio.h>
extern int yylex(void);
extern int yyerror(char *);
%}

/* declare tokens */
%token NUMBER
%token OP_ADD OP_SUB OP_MUL OP_RGT OP_LFT OP_EQU

%%
calc:
 | calc exp OP_EQU    { printf("Y: RESULT = %d\n", $2); }
 ;

exp: factor
 | exp OP_ADD factor  { $$ = $1 + $3; }
 | exp OP_SUB factor  { $$ = $1 - $3; }
 ;

factor: term
 | factor OP_MUL term { $$ = $1 * $3; }
 ;

term: NUMBER
 | OP_LFT exp OP_RGT  { $$ = $2; }
  ;
%%

int main(int argc, char **argv)
{
  yyparse();
}

int yyerror(char *s)
{
  fprintf(stderr, "error: '%s'\n", s);
}

Créons example.l :

/* calculator source for flex */
%{
#include "example.tab.h"
%}

%%
[0-9]+ { printf("L: NUMBER = %s\n", yytext); yylval = atoi(yytext); return NUMBER; }
"+"    { printf("L: OP_ADD\n"); return OP_ADD; }
"-"    { printf("L: OP_SUB\n"); return OP_SUB; }
"*"    { printf("L: OP_MUL\n"); return OP_MUL; }
"("    { printf("L: OP_LFT\n"); return OP_LFT; }
")"    { printf("L: OP_RGT\n"); return OP_RGT; }
"="    { printf("L: OP_EQU\n"); return OP_EQU; }
"exit" { printf("L: exit\n");   return YYEOF; } /* YYEOF = 0 */
.      { /* ignore all other */ }
%%

Puis exécutons comme suit à partir de l’invite de l’interpréteur pour tester cet exemple :

$ bison -d example.y
$ flex example.l
$ gcc -lfl example.tab.c lex.yy.c -o example
$ ./example
1 + 2 * ( 3 + 1 ) =
L: NUMBER = 1
L: OP_ADD
L: NUMBER = 2
L: OP_MUL
L: OP_LFT
L: NUMBER = 3
L: OP_ADD
L: NUMBER = 1
L: OP_RGT
L: OP_EQU
Y: RESULT = 9

exit
L: exit

Des outils de type lint pour aider à l’analyse du code statique automatique.

Des outils de type Indent peuvent aider pour des révisions humaines du code en reformatant les codes sources de manière cohérente.

Des outils de type Ctags peuvent aider pour les révisions humaines de code en générant un fichier d’index (ou de balise) des noms trouvés dans les codes source.

[Astuce] Astuce

Configurer votre éditeur préféré (emacs ou vim) pour utiliser des extensions de moteur de vérification syntaxique asynchrone facilite l'écriture de votre code. Ces extensions deviennent très puissantes en tirant parti du Language Server Protocol. Comme elles évoluent rapidement, utiliser leur code amont au lieu du paquet Debian peut être une bonne option.

Tableau 12.12. Liste des outils d’analyse du code statique :

paquet popularité taille description
vim-ale I:0 2591 moteur de vérification syntaxique asynchrone pour Vim 8 et NeoVim
vim-syntastic I:3 1379 bidouilles de vérification de la syntaxe pour vim
elpa-flycheck V:0, I:1 808 vérification moderne de la syntaxe à la volée pour Emacs
elpa-relint V:0, I:0 147 recherche d’erreurs d’expressions rationnelles dans Emacs Lisp
cppcheck-gui V:0, I:1 7224 outil graphique d'analyse statique du code C/C++
shellcheck V:2, I:13 18987 outil d’analyse syntaxique pour les scripts d’interpréteur
pyflakes3 V:2, I:15 20 vérificateur passif des programmes en Python 3
pylint V:4, I:20 2018 vérificateur de code statique Python
perl V:707, I:989 673 interpréteur ayant un vérificateur de code statique interne : B::Lint(3perl)
rubocop V:0, I:0 3247 analyseur de code statique en Ruby
clang-tidy V:2, I:11 21 outil d’analyse de C++ basé sur clang
splint V:0, I:2 2320 outil pour vérifier de manière statique les bogues d’un programme en C
flawfinder V:0, I:0 205 outil pour examiner le code source en C/C++ et rechercher des faiblesses du point de vue de la sécurité
black V:3, I:13 660 formateur de code Python intransigeant
perltidy V:0, I:4 2493 indenteur et formateur de script Perl
indent V:0, I:7 431 programme de formatage de code source en langage C
astyle V:0, I:2 785 indenteur de code source pour C, C++, Objective-C, C# et Java
bcpp V:0, I:0 111 embellisseur pour C(++)
xmlindent V:0, I:1 53 reformateur de flux XML
global V:0, I:2 1908 outils de recherche et de navigation dans le code source
exuberant-ctags V:2, I:20 341 constructeur des index de fichiers de balises des définitions du code source
universal-ctags V:1, I:11 3386 constructeur des index de fichiers de balises des définitions du code source

Le débogage est une partie de l’activité de programmation. Savoir comment déboguer des programmes fera de vous un bon utilisateur de Debian qui pourra produire des rapports de bogues documentés.


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

Des bons tutoriels sur gdb sont disponibles :

  • « info gdb » ;

  • « Déboguer avec GDB » dans /usr/share/doc/gdb-doc/html/gdb/index.html ;

  • « tutoriel sur le web ».

Voici un exemple simple d’utilisation de gdb(1) sur un « programme » compilé avec l’option « -g » qui produit les informations de débogage :

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

Étant donné que par défaut tous les binaires installés doivent être réduits à l’essentiel sur le système Debian, la plupart des symboles de débogage sont supprimés dans les paquets normaux. Pour déboguer les paquets Debian avec gdb(1), les paquets *-dbgsym doivent être installés (par exemple, coreutils-dbgsym dans le cas de coreutils). Les paquets source génèrent automatiquement les paquets *-dbgsym avec les paquets binaires normaux et ces paquets de débogage sont placés séparément dans l’archive debian-debug. Veuillez vous référer aux articles sur le wiki de Debian pour plus d’informations.

Si un paquet à déboguer ne fournit pas son paquet *-dbgsym, vous devrez l’installer après l’avoir reconstruit comme suit  :

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

La trace d’appels peut être obtenue avec gdb en utilisant une des manières suivantes :

Pour une situation de boucle infinie ou de clavier gelé, vous pouvez forcer le plantage du programme en appuyant sur Ctrl-\ ou Ctrl-C ou en exécutant « kill -ABRT PID » (consulter la 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 est une suite d'outils de programmation conçus pour aider à rendre les paquets de code source portables sur de nombreux systèmes de type Unix .

  • Autoconf est un outil permettant de produire un script d’interpréteur « configure » à partir de « configure.ac ».

    • « configure » est utilisé ultérieurement pour produire un « Makefile » à partir du modèle « Makefile.in ».

  • Automake est un outil permettant de produire un « Makefile.in » à partir de « Makefile.am ».

  • Libtool est un script d’interpréteur permettant de résoudre le problème de portabilité des logiciels lors de la compilation de bibliothèques partagées à partir du code source.

Le système de construction des logiciels a évolué :

  • Autotools au-dessus de Make a été la norme de facto pour l'infrastructure de construction portable depuis les années 1990. Ce système est extrêmement lent ;

  • CMake, initialement publié en 2000, a considérablement amélioré la vitesse, mais il était à l'origine construit sur Make, intrinsèquement lent (aujourd'hui, Ninja peut être son dorsal) ;

  • Ninja initialement publié en 2012 est destiné à remplacer Make pour une meilleure vitesse de construction et est conçu pour que ses fichiers d'entrée soient générés par un système de construction de plus haut niveau ;

  • Meson, initialement publié en 2013, est le nouveau système de construction de haut niveau, populaire et rapide, qui utilise Ninja comme dorsal.

Consultez les documents disponibles dans « The Meson Build system » et « 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.

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

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

    • « https://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 https://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.



[7] Quelques ajustements peuvent être nécessaires pour qu’ils fonctionnent sur le système actuel.