Table des matières
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 | |
---|---|
N’utilisez pas « |
Attention | |
---|---|
Vous devrez installer les programmes directement compilés à partir des
sources dans « |
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).
Tableau 12.1. Liste de bashismes typiques
Bon : POSIX | À éviter : bashisme |
---|---|
if [ "$toto" = "$titi" ] ; then … |
if [ "$toto" == "$titi" ] ; then … |
diff -u fichier.c.orig fichier.c |
diff -u fichier.c{.orig,} |
mkdir /tototiti /tototutu |
mkdir /toto{titi,tutu} |
funcname() { … } |
function funcname() { … } |
format octal : « \377 » |
format hexadécimal : « \xff » |
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 | |
---|---|
Bien que l’option « |
Astuce | |
---|---|
Utilisez la commande « |
Des paramètres spéciaux de l’interpréteur de commandes sont souvent utilisés dans les scripts de l’interpréteur de commandes.
Tableau 12.2. Liste des paramètres de l’interpréteur de commandes
paramètre de l’interpréteur de commandes | valeur |
---|---|
$0 |
nom de l’interpréteur ou du script de l’interpréteur |
$1 |
premier (1er) paramètre de l’interpréteur |
$9 |
neuvième (9ème) paramètre de l’interpréteur |
$# |
nombres de paramètres positionnels |
"$*" |
"$1 $2 $3 $4 … " |
"$@" |
"$1" "$2" "$3" "$4" … |
$? |
valeur de retour de la commande la plus récente |
$$ |
PID de ce script de l’interpréteur de commandes |
$! |
PID de la tâche de fond la plus récemment lancée |
Les expansions de paramètre les plus courantes à retenir sont mentionnées ci-dessous :
Tableau 12.3. Liste des expansions de paramètre de l’interpréteur
forme de l’expression du paramètre | valeur si var est positionnée |
valeur si var n’est pas positionnée |
---|---|---|
${var:-chaîne} |
« $var » |
« chaîne » |
${var:+chaîne} |
« chaîne » |
« null » |
${var:=chaîne} |
« $var » |
« chaîne » (et lancer
« var=chaîne ») |
${var:?chaîne} |
« $var » |
echo « chaîne » vers stderr (et quitter avec une erreur) |
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
Tableau 12.4. Liste des substitutions-clés de paramètres de l’interpréteur
forme de substitution de paramètre | résultat |
---|---|
${var%suffixe} |
supprimer le motif de suffixe le plus petit |
${var%%suffixe} |
supprimer le motif de suffixe le plus grand |
${var#préfixe} |
supprimer le motif de préfixe le plus petit |
${var##préfixe} |
supprimer le motif de suffixe le plus grand |
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 | |
---|---|
« 0 » dans le contexte conditionnel de l’interpréteur signifie « Vrai » alors que « 0 » dans le contexte conditionnel de C signifie « Faux ». |
Note | |
---|---|
« |
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
».
Tableau 12.5. Liste des opérateurs de comparaison dans les expressions conditionnelles
équation | condition pour retourner une valeur logique vraie |
---|---|
-e fichier |
fichier existe |
-d fichier |
fichier existe et est un répertoire |
-f fichier |
fichier existe et est un fichier normal (« régulier ») |
-w fichier |
fichier existe et peut être écrit |
-x fichier |
fichier existe et est exécutable |
fichier1 -nt
fichier2 |
fichier1 est plus récent que fichier2 (modification) |
fichier1 -ot
fichier2 |
fichier1 est plus ancien que fichier2 (modification) |
fichier1 -ef
fichier2 |
fichier1 et fichier2 sont sur le même périphérique et le même numéro d’inœud |
Tableau 12.6. Liste des opérateurs de comparaison de chaîne de caractères dans les expressions conditionnelles
équation | condition pour retourner une valeur logique vraie |
---|---|
-z str |
la longueur de str est nulle |
-n str |
la longueur de str est non nulle |
str1 = str2 |
str1 et str2 sont égales |
str1 != str2 |
str1 et str2 ne sont pas égales |
str1 < str2 |
str1 est trié avant str2 (dépendant des paramètres linguistiques) |
str1 > str2 |
str1 est trié après str2 (dépendant des paramètres linguistiques) |
Les opérateurs de comparaison arithmétique entière dans les expressions
conditionnelles sont « -eq
»,
« -ne
», « -lt
»,
« -le
», « -gt
»
et « -ge
».
Il existe un certains nombre d’idiomes de boucles qu’on peut utiliser avec un interpréteur de commandes POSIX.
« for x in toto1 toto2 ... ; do commande ;
done
» boucle en assignant les éléments de la liste
« toto1 toto2 ...
» à la variable
« x
» et et en exécutant la
« commande
».
« "while condition ; do commande ; done
»
répète la « commande
» tant que la
« condition
» est vraie.
« until condition ; do commande ; done
» répète
la « commande
» tant que
« « condition
» n’est pas vraie.
« break
» permet de quitter la boucle.
« continue
» permet de reprendre l’itération
suivante de la boucle.
Astuce | |
---|---|
Les itérations numériques semblables à celles du langage C peuvent être réalisées en utilisant
|
Astuce | |
---|---|
Consultez Section 9.4.9, « Répéter une commande en bouclant entre des fichiers ». |
Some popular environment variables for the normal shell command prompt may not be available under the execution environment of your script.
For "$USER
", use "$(id -un)
"
For "$UID
", use "$(id -u)
"
For "$HOME
", use "$(getent passwd "$(id -u)"|cut
-d ":" -f 6)
" (this works also on Section 4.5.2, « Le système de gestion centralisée moderne »)
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.
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
.
Tableau 12.7. Lites des paquets comportant des petits programmes utilitaires pour les scripts de l’interpréteur de commandes
paquet | popcon | taille | description |
---|---|---|---|
dash
|
V:894, I:995 | 191 | small and fast POSIX-compliant shell for sh |
coreutils
|
V:908, I:999 | 18062 | utilitaires du cœur de GNU |
grep
|
V:799, I:999 | 1245 | GNU grep , egrep and
fgrep |
sed
|
V:792, I:999 | 987 | GNU sed |
mawk
|
V:391, I:997 | 263 | small and fast awk |
debianutils
|
V:919, I:999 | 243 | divers utilitaires spécifiques à Debian |
bsdutils
|
V:610, I:999 | 355 | utilitaires de base provenant de 4.4BSD-Lite |
bsdextrautils
|
V:454, I:548 | 337 | extra utilities from 4.4BSD-Lite |
moreutils
|
V:14, I:39 | 244 | utilitaires supplémentaires d’UNIX |
Astuce | |
---|---|
Although |
See Section 1.6, « Traitement des données textuelles à la UNIX » for examples.
Tableau 12.8. List of interpreter related packages
paquet | popcon | taille | documentation |
---|---|---|---|
dash
|
V:894, I:995 | 191 | sh: small and fast POSIX-compliant shell for
sh |
bash
|
V:821, I:999 | 7163 | sh: "info bash " provided by
bash-doc |
mawk
|
V:391, I:997 | 263 | AWK: small and fast awk |
gawk
|
V:313, I:402 | 2456 | AWK: "info gawk " provided by
gawk-doc |
perl
|
V:644, I:990 | 669 | Perl: perl (1) and html pages
provided by perl-doc and perl-doc-html |
libterm-readline-gnu-perl
|
V:2, I:30 | 379 | Perl extension for the GNU ReadLine/History Library:
perlsh (1) |
libreply-perl
|
V:0, I:0 | 171 | REPL for Perl: reply (1) |
libdevel-repl-perl
|
V:0, I:0 | 237 | REPL for Perl: re.pl (1) |
python3
|
V:726, I:931 | 80 | Python: python3 (1) and html
pages provided by python3-doc |
tcl
|
V:28, I:268 | 22 | Tcl: tcl (3) and detail manual
pages provided by tcl-doc |
tk
|
V:22, I:261 | 22 | Tk: tk (3) and detail manual
pages provided by tk-doc |
ruby
|
V:112, I:254 | 29 | Ruby: ruby (1),
erb (1), irb (1),
rdoc (1), ri (1) |
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.
Most interpreters offer basic syntax check and code tracing functionalities.
“dash -n script.sh” - Syntax check of a Shell script
“dash -x script.sh” - Trace a Shell script
“python -m py_compile script.py” - Syntax check of a Python script
“python -mtrace --trace script.py” - Trace a Python script
“perl -I ../libpath -c script.pl” - Syntax check of a Perl script
“perl -d:Trace script.pl” - Trace a Perl script
For testing code for dash
, try Section 9.1.4, « Readline wrapper » which accommodates
bash
-like interactive environment.
For testing code for perl
, try REPL environment for Perl
which accommodates Python-like REPL (=READ + EVAL + PRINT + LOOP)
environment for Perl.
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.
Tableau 12.9. List of dialog programs
paquet | popcon | taille | description |
---|---|---|---|
x11-utils
|
V:169, I:556 | 712 | xmessage (1) : afficher un message ou une question
dans une fenêtre (X) |
whiptail
|
V:258, I:996 | 57 | afficher des boîtes de dialogues conviviales depuis des scripts de l’interpréteur de commandes (newt) |
dialog
|
V:13, I:113 | 1213 | afficher des boîtes de dialogues conviviales depuis des scripts de l’interpréteur de commandes (ncurses) |
zenity
|
V:74, I:356 | 167 | display graphical dialog boxes from shell scripts (GTK) |
ssft
|
V:0, I:0 | 75 | Outil frontal de scripts de l’interpréteur de commandes (enrobeur pour zenity, kdialog et dialog avec gettext) |
gettext
|
V:55, I:278 | 5825 | « /usr/bin/gettext.sh »: traduire des messages |
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.
GUI filer programs can be extended to perform some popular actions on selected files using additional extension packages. They can also made to perform very specific custom actions by adding your specific scripts.
For GNOME, see NautilusScriptsHowto.
For KDE, see Creating Dolphin Service Menus.
For Xfce, see Thunar - Custom Actions and https://help.ubuntu.com/community/ThunarCustomActions.
For LXDE, see Custom Actions.
In order to process data, sh
needs to spawn sub-process
running cut
, grep
,
sed
, etc., and is slow. On the other hand,
perl
has internal capabilities to process data, and is
fast. So many system maintenance scripts on Debian use
perl
.
Let's think following one-liner AWK script snippet and its equivalents in Perl.
awk '($2=="1957") { print $3 }' |
Il est équivalent à l’une quelconque des lignes suivantes :
perl -ne '@f=split; if ($f[1] eq "1957") { print "$f[2]\n"}' |
perl -ne 'if ((@f=split)[1] eq "1957") { print "$f[2]\n"}' |
perl -ne '@f=split; print $f[2] if ( $f[1]==1957 )' |
perl -lane 'print $F[2] if $F[1] eq "1957"' |
perl -lane 'print$F[2]if$F[1]eq+1957' |
La dernière est une devinette. Elle tire parti des fonctionnalités suivantes de Perl :
L’espace est optionnel.
Il existe une conversion automatique des nombres en chaîne de caractères.
Perl execution tricks via command line options:
perlrun
(1)
Perl special variables: perlvar
(1)
This flexibility is the strength of Perl. At the same time, this allows us to create cryptic and tangled codes. So be careful.
For more crazy Perl scripts, Perl Golf may be interesting.
Tableau 12.10. List of compiler related packages
paquet | popcon | taille | description |
---|---|---|---|
gcc
|
V:153, I:565 | 47 | GNU C compiler |
libc6-dev
|
V:246, I:581 | 11954 | GNU C Library: Development Libraries and Header Files |
g++
|
V:56, I:503 | 14 | GNU C++ compiler |
libstdc++-10-dev
|
V:38, I:269 | 17587 | GNU Standard C++ Library v3 (development files) |
cpp
|
V:317, I:727 | 30 | GNU C preprocessor |
gettext
|
V:55, I:278 | 5825 | GNU Internationalization utilities |
glade
|
V:0, I:6 | 1209 | GTK User Interface Builder |
valac
|
V:0, I:5 | 717 | C# like language for the GObject system |
flex
|
V:8, I:82 | 1260 | LEX-compatible fast lexical analyzer generator |
bison
|
V:8, I:89 | 3116 | YACC-compatible parser generator |
susv2
|
I:0 | 16 | aller chercher « The Single UNIX Specifications v2 » |
susv3
|
I:0 | 16 | aller chercher « The Single UNIX Specifications v3 » |
golang
|
I:20 | 12 | Go programming language compiler |
rustc
|
V:3, I:13 | 7753 | Rust systems programming language |
haskell-platform
|
I:4 | 12 | Standard Haskell libraries and tools |
gfortran
|
V:8, I:75 | 16 | GNU Fortran 95 compiler |
fpc
|
I:3 | 102 | Free Pascal |
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)
Un exemple simple « example.c
» peut être
compilé avec la bibliothèque « libm
» pour
donner l’exécutable « run_example
» par ce qui
suit :
$ cat > example.c << EOF #include <stdio.h> #include <math.h> #include <string.h> int main(int argc, char **argv, char **envp){ double x; char y[11]; x=sqrt(argc+7.5); strncpy(y, argv[0], 10); /* prevent buffer overflow */ y[10] = '\0'; /* fill to make sure string ends with '\0' */ printf("%5i, %5.3f, %10s, %10s\n", argc, x, y, argv[1]); return 0; } EOF $ gcc -Wall -g -o run_example example.c -lm $ ./run_example 1, 2.915, ./run_exam, (null) $ ./run_example 1234567890qwerty 2, 3.082, ./run_exam, 1234567890qwerty
Ici, « -lm
» est nécessaire pour lier la
bibliothèque « /usr/lib/libm.so
» depuis le
paquet libc6
pour sqrt
(3). La
bibliothèque réelle se trouve dans « /lib/
»
avec le nom de fichier « libm.so.6
» avec un
lien symbolique vers « libm-2.7.so
».
Regardez le dernier paramètre du texte en sortie. Il y a plus de 10
caractères bien que « %10s
» soit indiqué.
L’utilisation de fonctions effectuant des opérations sur des pointeurs en
mémoire sans vérification des limites, telles que
sprintf
(3) et strcpy
(3) a été rendue
obsolète afin d’éviter les exploits de débordements de tampons qui utilisent
les effets des débordements ci-dessus. Utilisez
snprintf
(3) et strncpy
(3) en
remplacement..
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.
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.
%% %%
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 | |
---|---|
Configuring your favorite editor ( |
Tableau 12.12. Liste des outils d’analyse du code statique :
paquet | popcon | taille | description |
---|---|---|---|
vim-ale
|
I:0 | 2591 | Asynchronous Lint Engine for Vim 8 and NeoVim |
vim-syntastic
|
I:3 | 1379 | Syntax checking hacks for vim |
elpa-flycheck
|
V:0, I:1 | 792 | modern on-the-fly syntax checking for Emacs |
elpa-relint
|
V:0, I:0 | 135 | Emacs Lisp regexp mistake finder |
cppcheck-gui
|
V:0, I:1 | 6196 | tool for static C/C++ code analysis (GUI) |
shellcheck
|
V:2, I:11 | 18987 | lint tool for shell scripts |
pyflakes3
|
V:1, I:14 | 24 | passive checker of Python 3 programs |
pylint
|
V:4, I:17 | 1976 | vérificateur de code statique Python |
perl
|
V:644, I:990 | 669 | interpréteur ayant un vérificateur de code statique interne :
B::Lint (3perl) |
rubocop
|
V:0, I:0 | 3247 | Ruby static code analyzer |
clang-tidy
|
V:1, I:8 | 21 | clang-based C++ linter tool |
splint
|
V:0, I:3 | 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:2, I:8 | 557 | uncompromising Python code formatter |
perltidy
|
V:0, I:4 | 2338 | Perl script indenter and reformatter |
indent
|
V:0, I:9 | 426 | C language source code formatting program |
astyle
|
V:0, I:3 | 761 | Source code indenter for C, C++, Objective-C, C#, and Java |
bcpp
|
V:0, I:0 | 111 | C(++) beautifier |
xmlindent
|
V:0, I:1 | 53 | XML stream reformatter |
global
|
V:1, I:2 | 1896 | Source code search and browse tools |
exuberant-ctags
|
V:3, I:25 | 345 | build tag file indexes of source code definitions |
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
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 | |
---|---|
De nombreuses commandes de |
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:
Crash-in-GDB approach:
Run the program from GDB.
Crash the program.
Type "bt
" at the GDB prompt.
Crash-first approach:
Update the “/etc/security/limits.conf” file to include the following:
* soft core unlimited
Type "ulimit -c unlimited
" to the shell prompt.
Run the program from this shell prompt.
Crash the program to produce a core dump file.
Load the core dump file to GDB as
"gdb gdb ./program_binary core
" .
Type "bt
" at the GDB prompt.
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 | |
---|---|
Souvent, vous voyez une trace où une ou plusieurs des lignes de départ se
trouvent dans « $ MALLOC_CHECK_=2 gdb hello |
Tableau 12.14. Liste des commandes avancées de gdb
commande | description des objectifs des commandes |
---|---|
(gdb) thread apply all bt |
obtenir une trace de tous les processus d’un programme multi-processus (multi-threaded) |
(gdb) bt full |
obtenir les paramètres qui se trouvent sur la pile d’appel des fonctions |
(gdb) thread apply all bt full |
obtenir une trace et les paramètres en combinant les options précédentes |
(gdb) thread apply all bt full 10 |
obtenir une trace et les paramètres des 10 premiers appels en supprimant ce qui n’est pas significatif |
(gdb) set logging on |
écrire le journal de sortie de gdb dans un fichier (le
fichier par défaut est « gdb.txt ») |
Utilisez ldd
(1) pour trouver les dépendances d’un
programme avec des bibliothèques :
$ ldd /bin/ls librt.so.1 => /lib/librt.so.1 (0x4001e000) libc.so.6 => /lib/libc.so.6 (0x40030000) libpthread.so.0 => /lib/libpthread.so.0 (0x40153000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Pour que ls
(1) fonctionne dans un environnement
`chroot`é, les bibliothèques ci-dessus doivent être disponibles dans votre
environnement `chroot`é.
Consultez Section 9.4.6, « Tracer l’activité d’un programme ».
There are several dynamic call tracing tools available in Debian. See Section 9.4, « Surveiller, contrôler et démarrer l’activité des programmes ».
Si un programme apercu1
de GNOME a reçu une erreur X,
vous devriez obtenir un message comme suit :
The program 'preview1' received an X Window System error.
Dans ce cas, vous pouvez essayer de faire tourner le programme avec
« --sync
» et arrêter sur la fonction
« gdk_x_error
» de manière à obtenir une trace.
Il y a plusieurs outils de détection des fuites de mémoire disponibles sous Debian.
Tableau 12.15. Liste des outils de détection des fuites de mémoire
paquet | popcon | taille | description |
---|---|---|---|
libc6-dev
|
V:246, I:581 | 11954 | mtrace (1) : fonctionnalité de débogage de malloc
dans glibc |
valgrind
|
V:6, I:38 | 77683 | débogueur mémoire et optimiseur |
electric-fence
|
V:0, I:4 | 73 | débogueur malloc (3) |
libdmalloc5
|
V:0, I:3 | 393 | bibliothèque de débogage de l’allocation mémoire |
duma
|
V:0, I:0 | 293 | library to detect buffer overruns and under-runs in C and C++ programs |
leaktracer
|
V:0, I:2 | 56 | traceur de fuites de mémoire pour les programmes C++ |
Tableau 12.16. List of build tool packages
paquet | popcon | taille | documentation |
---|---|---|---|
make
|
V:147, I:574 | 1592 | « info make » fourni par
make-doc |
autoconf
|
V:33, I:257 | 2025 | « info autoconf » fourni par
autoconf-doc |
automake
|
V:34, I:256 | 1837 | « info automake » fourni par
automake1.10-doc |
libtool
|
V:29, I:240 | 1213 | "info libtool " provided by libtool-doc |
cmake
|
V:16, I:116 | 28897 | cmake (1) cross-platform, open-source make system |
ninja-build
|
V:5, I:34 | 417 | ninja (1) small build system closest in spirit to Make |
meson
|
V:2, I:20 | 3451 | meson (1) high productivity build system on top of
ninja |
xutils-dev
|
V:1, I:10 | 1485 | imake (1), xmkmf (1), etc. |
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.
Tableau 12.17. Liste des variables automatiques de make
variables automatiques | valeur |
---|---|
$@ |
cible |
$< |
première exigence |
$? |
toutes les exigences plus récentes |
$^ |
toutes les exigences |
$* |
« % » correspond au radical dans le motif cible |
Tableau 12.18. Liste de l’expansion des variables de make
expansion de la variable | description |
---|---|
toto := titi |
expansion à la volée |
toto2 = titi |
expression récursive |
toto3+= titi |
ajouter |
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.
Avertissement | |
---|---|
Ne pas écraser les fichiers du système avec les programmes que vous avez compilés en les installant. |
Debian ne touche pas aux fichiers se trouvant dans
« /usr/local/
» ou
« /opt
». Donc, si vous compilez un programme
depuis ses sources, installez-le dans
« /usr/local/
» de manière à ce qu’il
n’interfère pas avec Debian.
$ cd src $ ./configure --prefix=/usr/local $ make # this compiles program $ sudo make install # this installs the files in the system
Si vous avez les sources d’origine et s’ils utilisent
autoconf
(1) et automake
(1) et si
vous-vous souvenez comment vous l’avez configuré, exécutez-le comme suit
pour désinstaller le programme :
$ ./configure all-of-the-options-you-gave-it
$ sudo make uninstall
Sinon, si vous êtes absolument certain que le processus d’installation n’a
mis des fichiers que sous « /usr/local/
» et
qu’il n’y a là rien d’important, vous pouvez supprimer tout son contenu
avec :
# find /usr/local -type f -print0 | xargs -0 rm -f
If you are not sure where files are installed, you should consider using
checkinstall
(8) from the checkinstall
package, which provides a clean path for the uninstall. It now supports to
create a Debian package with "-D
" option.
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.
Tableau 12.19. Liste des outils de conversion de code source
paquet | popcon | taille | mot clé | description |
---|---|---|---|---|
perl
|
V:644, I:990 | 669 | AWK→PERL | convertir le code source de AWK vers PERL : a2p (1) |
f2c
|
V:0, I:4 | 442 | FORTRAN→C | convertir le code source de FORTRAN 77 vers C/C++ :
f2c (1) |
intel2gas
|
V:0, I:0 | 178 | intel→gas | convertisseur depuis NASM (format Intel) vers l’Assembleur GNU (GAS) |
Si vous désirez créer un paquet Debian, lisez ce qui suit :
Chapitre 2, Gestion des paquets Debian pour comprendre les bases du système de paquets
Section 2.7.13, « Porter un paquet vers le système stable » pour comprendre les bases du processus de portage
Section 9.11.4, « Système protégé (chroot) » pour comprendre les techniques de base d’un environnement isolé (« chroot »)
debuild
(1), and sbuild
(1)
Section 12.5.2, « Déboguer un paquet Debian » pour recompiler avec les informations de débogage
Guide pour les responsables
Debian (le paquet debmake-doc
)
Référence du développeur
Debian (paquet developers-reference
)
Charte Debian (paquet
debian-policy
)
Il existe des paquets tels que debmake
,
dh-make
, dh-make-perl
, etc., qui
facilitent la réalisation des paquets.