Programmation en PERL

Bien que CPAN contiennent le code source complet de Perl, plus quelques distributions binaires pour les systèmes privés de compilateurs C, ainsi que quelques programmes, CPAN est surtout connu pour sa collection de modules.

Lorsque nous parlons de « modules », nous voulons dire trois choses : de purs modules Perl à 100 % (décrits aux chapitres 11 et 12), des extensions (des modules dépendant de code C, décrits au chapitre 21) et des pragmas (des modules contenant des instructions spéciales pour le compilateur de Perl, décrits au chapitre 31). Il existe également sur CPAN des bundles (groupements) de modules. Les bundles sont des collections de modules qui interagissent d'une manière ou d'une autre et qui sont généralement la production d'un développeur de modules désirant fournir une solution autonome à un ensemble de problèmes. Si un module dépend d'un autre (et éventuellement d'une version spécifique), les développeurs grouperont souvent les modules dans un bundle. Voir par exemple Bundle-XML.

Une façon de parcourir les modules de CPAN est de vous rendre à l'adresse http://search.cpan.org, qui fournit un frontal de moteur de recherche pour CPAN. Une autre manière est de vous rendre sur votre miroir local de CPAN et d'entrer dans le répertoire modules, où vous verrez trois sous-répertoires : by-authors, by-category et by-module (par auteur, par catégorie et par module). Le répertoire by-module peut être le plus utile si votre navigateur possède une fonctionnalité de recherche — bien que (lamentablement) certains modules ne sont disponibles que dans les répertoires sous author. Si vous recherchez par catégorie, vous obtiendrez les choix suivants :

Perl core modules, langage extensions, and documentation tools

• (Modules centraux de Perl, extensions de langage et outils pour la documentation)
  Cette catégorie comprend des pragmas et d'autres modules standards, des modules qui vous aident à écrire différemment en Perl, des modules en rapport avec le compilateur de Perl, des filtres pour le code source et des modules en rapport avec pod, le format de documentation de Perl. Cette catégorie comprend également des modules pour générer du bytecode Java.

Development support

• (Support du développement)
  Cette catégorie comprend des modules pour en créer d'autres et examiner comment Perl lance des programmes.

Operating system interfaces and hardware drivers

• (Interfaces de systèmes d'exploitation et pilotes matériels)
  Vous trouverez ici des modules pour interagir avec des entités étranges comme des systèmes d'exploitation, des PalmPilots ou des ports série.

Networking, device control and interprocess communication

• (Communication réseau, contrôle de périphériques et communication interprocessus)
  Ceci comprend des modules implémentant des protocoles réseau, manipulant des données réseau, maniant des modems et contrôlant les appareils électroménagers de votre maison.

Data types and data type utilities

• (Types de données et utilitaires pour les types de données)
  Cette catégorie contient des modules pour les maths, les statistiques, les algorithmes, les structures de données (et leurs sauvegardes persistantes), les dates et les heures, la programmation orientée objet, le PDL (le langage de données de Perl (Perl Data Language)) et le POE (l'environnement objet de Perl (Perl Object Environment), un ordonnanceur événementiel orienté objet).

Database interfaces

• (Interfaces de bases de données)
  Vous trouverez ici des modules vous permettant d'exploitant plusieurs douzaines de systèmes de bases de données en Perl, la plupart d'entre elles avec le système DBI de Perl. Cette catégorie inclut les modules DBD spécifiques à chaque base de données.

User interfaces (character and graphical)

• (Interfaces utilisateur (en mode caractères et graphique))
  Cette catégorie comprend des modules pour manipuler les terminaux utilisateur (édition de la ligne de commande et graphiques en mode caractères dans le style de curses(3)), ainsi que Perl/Tk et les liens avec Gtk, Gnome, Sx et Qt pour écrire vos propres interfaces graphiques en Perl.

Interfaces to or emulations of other programming languages

• (Interfaces vers ou émulations d'autres langages de programmation)
  Cette catégorie contient des modules pour utiliser d'autres langages de programmation depuis Perl ou vous permettre de prétendre que Perl n'est pas ce qu'il prétend être. Si vous êtes intéressés par utiliser Perl en C ou C en Perl, voir le chapitre 21.

Filenames, filesystems, and file locking

• (Noms de fichier, systèmes de fichiers et verrous de fichier)
  Cette catégorie comprend des modules pour inspecter, créer, verrouiller et tout ce qui concerne la manipulation de fichiers et de répertoires.

String processing, language text processing, parsing, and searching

• (Traitement de chaînes et traitement, analyse et recherche de langages textuels)
  Cette catégorie contient des modules pour manipuler du texte : placer des césures, enrober, analyser, rechercher des variations grammaticales et faire des recherches. Elle comprend des modules pour manipuler du PostScript, des fontes, du XML et du RTF.

Option, argument, parameter, and configuration file processing

• (Traitement d'options, d'arguments, de paramètres et de fichiers de configuration)
  Cette catégorie contient des modules pour traiter les arguments de la ligne de commande (le -x dans mon_prog_perl -x) et pour gérer des fichiers de configuration (comme les fichiers commençant par un point).

Internationalization and locale

• (Internationalisation et locales)
  Cette catégorie comprend des modules pour tailler sur mesure vos programmes pour un pays et une langue particuliers.

Authentication, security, and encryption

• (Authentification, sécurité et cryptage)
  Vous trouverez ici des modules pour gérer des mots de passe d'utilisateurs, calculer des signatures de messages, crypter des données et authentifier des utilisateurs.

World Wide Web, HTML, HTTP, CGI, MIME

Server and daemon utilities

• (N.d.T. Vous avez compris sans traduction, non ?)
  Cette catégorie contient des modules vous permettant de créer des pages web à base de CGI, des arpenteurs web et des systèmes de gestion de contenus basés sur le web. D'autres modules vous permettent de gérer les cookies, d'analyser du HTML et des messages MIME et de manipuler des caches web. Il existe également une section spéciale uniquement consacrée aux modules Perl que vous pouvez intégrer dans le serveur web Apache.
• (Utilitaires pour les serveurs et les démons)
  Cette catégorie comprend des modules pour créer des serveurs de réseau et d'événements.

Archiving, compression, and conversion

• (Archivage, compression et conversion)
  Vous trouverez ici des modules pour manipuler des fichiers zip et tar et pour faire des conversions entre des formats de fichiers (même le format de fichier d'Apple II).

Images, pixmap, and bitmap manipulation, drawing, and graphing

• (Manipulations d'images, de cartes de pixels et de bits, dessins et graphiques)
  Cette catégorie contient des modules pour créer des graphiques, des GIF, du VRML et travailler avec Gimp.

Mail and Usenet news

• (N.d.T. Vous avez compris sans traduction, non ?)
  Dans cette catégorie, vous trouverez des modules pour envoyer, recevoir et filtrer les mails et les news.

Control flow utilities

• (Utilitaires de contrôle de flux)
  Cette catégorie contient des modules pour exécuter du code Perl de temps à autre.

Filehandle, directory handle, and input/output stream utilities

• (Utilitaires pour les handles de fichiers, les handles de répertoires et les flux d'entrées/sorties)
  Ici se trouvent des modules pour les entrées depuis des fichiers et les sorties dans des fichiers, y compris des fichiers journaux (log). Ceci comprend tous les modules IO:: et un module Expect pour automatiser les dialogues avec des services réseau ou d'autres programmes interactifs.

Microsoft Windows modules

• (N.d.T.  Vous avez compris sans traduction, non ?)
  Cette catégorie comprend des modules pour manipuler la base de registre de Windows, ASP, ODBC, OLE et d'autres technologies spécifiques à Windows.

Miscellaneous modules

• (Modules divers)
  Vous trouverez ici des modules pour l'astronomie, la biologie, la chimie, la validation (ou l'invalidation) de cartes de crédit, les amortissements d'hypothèques, l'audio, la vidéo, la norme MIDI, la météo et les jeux.

La plupart des modules que vous trouverez sur CPAN sont dans un format « tarball ». C'est-à-dire qu'ils possèdent une extension de fichier en tar.gz et qu'ils sont décompressés dans un répertoire avec le code du module et tous les fichiers annexes, comprenant généralement un fichier README et un fichier Makefile.PL.

Quatre étapes rendent accessibles les modules de CPAN depuis vos programmes : la décompression, le dépaquetage, la construction et l'installation. La manière dont fonctionne chacune de ces étapes dépend de votre système d'exploitation et du module que vous installez, nous ne pouvons donc pas vous donner de recette à toute épreuve qui fonctionnerait à chaque fois. Lorsque vous doutez, lisez les fichiers README et INSTALL qui sont, espérons-le, distribués avec le module. Lisez également la page de manuel de perlmodinstall.

Mais il se peut que vous n'ayez jamais à réfléchir à la procédure d'installation si vous utilisez le module CPAN (livré avec la distribution de Perl) ou PPM (Perl Package Manager, le gestionnaire de paquetages Perl, livré avec la distribution ActiveState de Perl). Pour utiliser le module CPAN (à ne pas confondre avec CPAN, lui-même), tapez :

% perl -MCPAN -e "shell"

sur votre ligne de commande pour commencer le processus de configuration. Après avoir répondu à une variété de questions sur la manière dont vous préférez récupérer des fichiers, vous pouvez installer un module en tapant :

install Un::Module

dans le shell du module CPAN, ou en tapant :

% perl -MCPAN -e "install 'Un::Module'"

sur votre ligne de commande ordinaire.

Si vous ne disposez pas des avantages pratiques du module CPAN ou de PPM, vous devrez passer à la main les étapes décrites dans les paragraphes suivants. Les instructions sont données pour Unix, Windows et Macintosh ; pour d'autres systèmes d'exploitation, consultez la page de manuel de perlmodinstall.

22-2-a. Décompression et dépaquetage des modules de CPAN ▲

22-2-b. Construction des modules de CPAN ▲

% perl Makefile.PL 
% make 
% make test

22-2-c. Installation des modules de CPAN dans la bibliothèque Perl ▲

% perl -V

% make install

% perl Makefile.PL LIB=/mon/rep/perllib \
        INSTALLMAN1DIR=/mon/rep/man/man1 \
        INSTALLMAN3DIR=/mon/rep/man/man3 \
            INSTALLBIN=/mon/rep/bin \
         INSTALLSCRIPT=/mon/rep/scripts

use lib "/mon/rep/perllib";

Si vous avez un module dont vous pensez qu'il puisse être utile aux autres, envisagez de rendre le monde meilleur en le téléchargeant sur CPAN. Le serveur qui gère les soumissions de nouveaux modules est appelé PAUSE (Perl Authors Upload Server, le serveur de téléchargement des auteurs Perl) et on peut le trouver sur https://pause.kbx.de/pause/. Avant de pouvoir télécharger votre module, vous devrez obtenir un compte sur PAUSE. C'est un peu comme devenir un « développeur Perl répertorié ».

Si vous vous considérez vous-même comme un développeur Perl répertorié, vous devriez en savoir assez pour documenter vos modules. Perl possède une convention pour inclure la documentation à l'intérieur de votre code source. (De cette manière, vous ne l'égarez jamais.) Cette documentation incluse se trouve dans un format appelé « pod » (pour Plain Old Documentation, bonne vieille documentation) et est décrite au chapitre 26.

Vous devriez envisager de sécuriser votre module du point de vue des threads. Voir le chapitre 17, Threads.

Vous devriez également vous inquiéter quelque peu si votre joli petit module fait ou non des choses risquant de perturber la sécurité des gens qui l'utilisent, car les autres peuvent avoir de véritables bonnes raisons d'être plus concernés par la sécurité que vous ne l'êtes (POUR L'INSTANT). Voir le chapitre 23, Sécurité, pour tout savoir comment éviter d'être tenu responsable de la 3e Guerre Mondiale et d'autres nuisances du même acabit.

Les modules destinés à être distribués sur CPAN doivent inclure un programme Perl appelé Makefile.PL qui, lorsqu'on le lance, génère un Makefile, ainsi qu'un fichier README décrivant brièvement ce que fait le module et comment l'installer. Le Makefile s'attend à comporter également une série de tests. Vous pouvez créer tous ces fichiers d'un coup grâce à l'utilitaire h2xs :

h2xs -X -n Truc::Machin

(Remplacez -X par -A si vous construisez un module comprenant un composant XS. XS est décrit au chapitre 21.) Le programme h2xs crée un seul répertoire avec des squelettes de fichiers que vous devrez garnir de chair. Lorsque vous avez terminé, vous pouvez télécharger le répertoire dans un tarball sur PAUSE.

Le Makefile.PL généré par h2xs ressemblera à quelque chose comme ceci :

use ExtUtils::MakeMaker;
# See lib/ExtUtils/MakeMaker.pm for details of how to influence 
# the contents of the Makefile that is written. 
WriteMakefile(
    NAME         => 'Mon_test',
    VERSION_FROM => 'Mon_test.pm', # finds $VERSION
    LIBS         => [''], # e.g., '-lm'
    DEFINE       => '',   # e.g., '-DHAVE_SOMETHING'
    INC          => '',   # e.g., '-I/usr/include/other' 
);

La première chose que fait le Makefile.PL est de charger le module ExtUtils::MakeMaker. La fonction WriteMakefile de MakeMaker possède une pléthore d'options (avec une pléthore valant approximativement 88) pour vous aider à personnaliser ce qui se passe après que l'utilisateur a téléchargé votre module depuis CPAN et a tapé perl Makefile.PL pour commencer sa construction. La bonne nouvelle à propos de tout ceci est que, puisque l'utilisateur est supposé lancer le perl qui sera utilisé plus tard, vous disposez d'une large étendue d'informations de configuration disponibles (via le module Config ou la variable spéciale $^O) pour vous aider à décider comment diriger MakeMaker. D'un autre côté, MakeMaker est vraiment excellent pour trouver des valeurs par défaut satisfaisantes pour presque tout, ainsi le fichier squelette écrit par h2xs peut très bien contenir tout ce dont vous avez besoin avec peut-être un ou deux ajustements. Pour plus d'informations à ce sujet, voir la documentation en ligne très complète de ExtUtils::MakeMaker.

Lorsque vous écrivez un module Perl destiné à un usage général, vous devriez permettre que la version de Perl de l'utilisateur diffère de la vôtre. Vous devriez toujours inclure une description en anglais de toutes les dépendances (les versions particulières de Perl, des prérequis du système ou d'autres modules) dans le fichier README. De toute façon, cela ne suffira peut-être même pas, puisque quelqu'un qui utilise le module CPAN pour télécharger et installer automatiquement votre module ne verrait jamais cet avertissement. Vous devriez donc vérifier les dépendances dans le Makefile.PL. Voilà comment vous pourriez vous assurer que la personne qui télécharge votre module lance Perl 5.6 ou une version supérieure :

eval { require 5.6.0 }
    or die << 'FIN_DOC'; 
############ 
### This module requires lvaluable subroutines, which are not available 
### in versions of Perl earlier than 5.6. Please upgrade!
############ 
FIN_DOC

22-3-a. Tests internes ▲

22-3-b. Tests externes ▲

Perl facilite une programmation sécurisée même lorsque le programme est utilisé par quelqu'un de moins fiable que le programme lui-même. C'est-à-dire que certains programmes ont besoin d'accorder des privilèges limités à leurs utilisateurs, sans accorder inutilement d'autres privilèges. Les programmes setuid et setgid tombent dans cette catégorie sur Unix, comme d'autres programmes tournant avec des modes de privilèges variés sur d'autres systèmes d'exploitation qui implémentent de telles notions. Même sur les systèmes où ce n'est pas le cas, les mêmes principes s'appliquent aux serveurs réseau et à tout programme lancé par ces serveurs (comme les scripts CGI, les gestionnaires de listes de diffusion et les démons répertoriés dans /etc/inetd.conf). Tous ces programmes exigent un niveau de vigilance plus élevé que la moyenne.

Même les programmes lancés à partir de la ligne de commande sont parfois de bons candidats pour le mode de marquage, tout particulièrement s'ils sont destinés à être lancés par un utilisateur privilégié. Les programmes agissant sur des données non fiables, comme ceux qui génèrent des statistiques à partir de fichiers journaux ou qui utilisent LWP::* ou Net::* pour récupérer des données distantes, devraient probablement être lancés avec le marquage explicitement activé ; les programmes imprudents risquent d'être changés en « chevaux de Troie ». Puisque les programmes ne retirent aucune émotion à prendre des risques, il n'y a pas de raison pour qu'ils ne soient pas précautionneux.

Au regard des shells de la ligne de commande sur Unix, qui ne sont véritablement que des infrastructures pour appeler d'autres programmes, Perl est facile à programmer de manière sécurisée, car il est direct et autonome. À l'inverse de la plupart des langages de programmation shells, qui sont basés sur de nombreuses et mystérieuses passes de substitution sur chaque ligne du script, Perl emploie un modèle d'évaluation plus conventionnel comportant moins d'inconvénients cachés. De plus, comme le langage intègre plus de fonctionnalités internes, il dépend moins de programmes externes (dont la fiabilité peut être mise en doute) pour accomplir son devoir.

Sous Unix, le berceau de Perl, le meilleur moyen de compromettre la sécurité du système est de couvrir de flatteries un programme privilégié pour qu'il fasse quelque chose pour lequel il n'est pas prévu. Pour parer de telles attaques, Perl a développé une approche unique pour faire face aux environnements hostiles. Perl active automatiquement le mode de marquage chaque fois qu'il détecte que son programme tourne avec des ID d'utilisateur ou de groupe réels et effectifs différents.(166) Même si le fichier contenant votre script Perl ne possède pas de bit setuid ou setgid activé, ce script peut toujours se retrouver lancé en mode de marquage. Cela se produit si votre script a été invoqué par un autre programme, qui lui-même était lancé sous des ID différents. Les programmes Perl qui ne sont pas conçus pour fonctionner en mode de marquage tendent à expirer prématurément lorsqu'ils sont surpris à violer la politique de marquage de sécurité. Perl n'est pas si crédule.

Vous pouvez également activer explicitement le mode de marquage en utilisant l'option de la ligne de commande -T. Vous devriez le faire pour les démons, les serveurs et les programmes qui tournent pour le compte de quelqu'un d'autre, comme les scripts CGI. Les programmes qui se lancent à distance et anonymement par quelqu'un sur le Net sont exécutés dans le plus hostile des environnements. Vous ne devriez pas craindre de dire « Non ! » de temps en temps. Contrairement à la croyance populaire, vous pouvez faire preuve d'une grande prudence sans pour autant vous transformer en prude faussement effarouchée.

Sur les sites les plus consciencieux en matière de sécurité, lancer tous les scripts CGI avec l'option -T n'est pas seulement une bonne idée : c'est la règle. Nous ne prétendons pas que lancer les scripts en mode de marquage est suffisant pour les rendre sécurisés. Ce n'est pas le cas et cela prendrait un livre entier pour seulement mentionner tout ce qu'il faudrait faire. Mais si vous n'exécutez pas vos scripts CGI en mode de marquage, vous faites inutilement l'impasse sur la protection la plus forte que Perl puisse vous offrir.

Pendant qu'il se trouve en mode de marquage, Perl prend des précautions particulières appelées vérifications du marquage (taint checks) pour se prémunir contre les pièges qu'ils soient triviaux ou subtils. Certaines de ces précautions sont assez simples, comme de vérifier que les variables d'environnement dangereuses ne sont pas positionnées et que les répertoires de votre PATH ne sont pas modifiables par quelqu'un d'autre ; les programmeurs prudents ont toujours procédé ainsi. D'autres vérifications sont toutefois mieux assurées par le langage lui-même et ce sont celles-là qui contribuent à rendre un programme Perl privilégié plus sûr que le programme C correspondant ou un script CGI en Perl plus sécurisé que le même script dans un langage sans vérifications de marquage. (C'est-à-dire, pour autant que nous le sachions, tous les langages à part Perl.)

Le principe est simple : vous ne pouvez pas utiliser des données dérivées de l'extérieur d'un programme pour affecter quelque chose d'autre en dehors de ce programme — du moins, pas accidentellement. Tout ce qui provient de l'extérieur du programme est marqué, ce qui comprend tous les arguments de la ligne de commande, les variables d'environnement et les fichiers en entrée. Les données marquées ne peuvent être utilisées directement ou indirectement dans toute opération invoquant un sous-shell ou modifiant des fichiers, des répertoires ou des processus. Toute variable positionnée dans une expression ayant précédemment référencé une valeur marquée devient elle-même marquée, même s'il est logiquement impossible que la valeur marquée ait influencé la variable. Le marquage étant associé à chaque valeur scalaire, certaines valeurs individuelles d'un tableau ou d'un hachage peuvent être marqués et d'autres non. (Seules les valeurs dans un hachage peuvent être marquées et non les clefs.)

Le code suivant illustre comment le marquage fonctionnerait si vous exécutiez toutes ces instructions dans l'ordre. Les instructions indiquées « Non sûres » lèveraient une exception, contrairement à celles qui sont « OK ».

$arg = shift(@ARGV);     # $arg est maintenant marqué (à cause de @ARGV).
$cache = "$arg, 'truc'";     # $cache est aussi marqué (à cause de $arg).
$ligne = <>;              # Marqué (lu à partir d'un fichier externe).
$chemin = $ENV{PATH};        # Marqué à cause de %ENV, mais voir plus loin.
$perso = 'abc';              # Non marqué.

system "echo $perso";        # Non sûr avant que le PATH ne soit positionné.

system "echo $arg";          # Non sûr : utilise sh avec $arg marqué.
system "echo", $arg;         # OK une fois que le PATH est positionné
                             # (n'utilise pas sh).
system "echo $cache";        # Non sûr de deux façons : marqué et PATH.

$vieux_chemin = $ENV{PATH};  # $vieux_chemin est marqué (à cause de %ENV).
$ENV{PATH} = 'bin:/usr/bin'; # (R on d'autres programmes.) $nouveau_chemin = $ENV{PATH}; # $nouveau_chemin n'est PAS marqué.

delete @ENV{qw{IFS
               CDPATH
               ENV
               BASH_ENV}};   # Rend %ENV plus sûr.

system "echo $perso"; # OK, est sûr une fois que le PATH est réinitialisé.
system "echo $cache"; # Non sûr via $cache qui est marqué.

open(OUF, "< $arg"); # OK (ouvertures en lecture seule non vérifiées).
open(OUF, "> $arg");    # Non sûr (tentative d'écriture dans arg qui est
                        # marqué).

open(OUF, "echo $arg|") # Non sûr via $arg qui est marqué, mais...
    or die "impossible de faire un pipe sur echo : $!";

open(OUF,"-|")           # Considéré OK : voir ci-dessous pour
    or exec 'echo', $arg # l'exemption de marquage sur une liste
    or die "exec echo impossible : $!"; # exec-utée.

open(OUF,"-|", "echo", $arg) # Comme précédemment, considéré OK.
    or die "impossible de faire un pipe sur un echo : $!";

$cri = `echo $arg`;    # Non sûr via $arg qui est marqué.
$cri = `echo abc`;     # $cri est marqué à cause des apostrophes inverses.
$cri2 = `echo $cri`;   # Non sûr via $cri qui est marqué.

unlink $perso, $arg;   # Non sûr via $arg qui est marqué.
umask $arg;            # Non sûr via $arg qui est marqué.

exec "echo $arg";      # Non sûr via $arg qui est marqué et passé au shell.
exec "echo", $arg;     # Considéré OK ! (Mais voir ci-dessous.)
exec "sh", '-c', $arg; # Considéré OK, mais à tort !

Si vous essayez de faire quelque chose de non sûr, vous obtiendrez une exception (qui devient une erreur fatale si elle n'est pas interceptée) comme « Insecure dependency » ou « Insecure $ENV{PATH} » (« Dépendance non sûre » ou « $ENV{PATH} non sûr ». Voir la section Nettoyage de votre environnement plus loin.

Si vous passez une LISTE à un system, un exec ou un open de pipe, les arguments ne sont pas inspectés pour vérifier s'ils sont marqués, car, avec une LISTE d'arguments, Perl n'a pas besoin d'invoquer le shell, qui est potentiellement dangereux, pour lancer la commande. Vous pouvez toujours écrire facilement un system, un exec ou un open de pipe non sûr en utilisant la forme avec LISTE, comme le démontre le dernier exemple ci-dessus. Ces formes sont exemptes de vérification, car vous êtes supposés savoir ce que vous faites lorsque vous les employez.

Parfois, vous ne pouvez toutefois pas dire combien d'arguments vous êtes en train de passer. Si vous fournissez à ces fonctions un tableau(167) qui ne contient qu'un élément, c'est alors exactement comme si vous passiez une chaîne en premier et le shell pourrait alors être utilisé. La solution est de passer un chemin explicite dans l'emplacement pour un objet indirect :

system @args;               # N'appellera pas le shell sauf si @args == 1. 
system { $args[0] } @args;  # Court-circuite le shell même avec une liste
                            # d'un seul argument.

23-1-a. Détection et blanchiment des données marquées ▲

sub est_marquee {
    my $arg = shift;
    my $nada = substr($arg, 0, 0); # longueur nulle
    local $@;  # préserve la version de l'appelant
    eval { eval "# $nada" };
    return length($@) != 0; 
}

if ($chaine =~ /^([-\@\w.]+)$/) {
    $chaine = $1;                    # $chaine est maintenant non marquée.
} else { 
   die "Mauvaises données dans $chaine"; # Enregistrez ceci quelque part. 
}

($rep, $fichier) = $chemin_complet =~ m!(.*/)(.*)!s;

{
    use re 'taint';
    ($rep, $fichier) = $chemin_complet =~ m!(.*/)(.*)!s; 
}

use re 'taint'; # le reste du fichier laisse maintenant $1, etc. marqués 
{
    no re 'taint';
    # ce bloc enlève maintenant le marquage dans les
    # correspondances d'expressions régulières
    if ($num =~ /^(\d+)$/) {
        $num = $1; 
    } 
}

use IO::Handle;

IO::Handle::untaint(*UN_HF);    # Soit de manière procédurale
UN_HF->untaint();                # soit en utilisant un style OO.

use File::stat;
use Symbol 'qualify_to_ref';

sub handle_semble_sur(*) {
    my $hf = qualify_to_ref(shift, caller);
    my $info = stat($hf);
    return unless $info;

    # le propriétaire n'est ni le super-utilisateur, ni « moi »,
    # dont l'uid réel est dans la variable $<
    if ( $info->uid != 0 && $info->uid != $< ) {
        return 0;
    }
    # vérifie si le groupe ou les autres peuvent écrire dans le fichier
    # utilise 066 pour détecter également la possibilité de lire
    if ( $info->mode & 022 ) {
        return 0;
    }
    return 1;
}

use IO::Handle;
UN_HF->untaint() if handle_semble_sur(*UN_HF);

$nouvelle_entree_du_livre_d_or =~ tr[_a-zA-Z0-9 ,.!?()@+*-][]dc;

23-1-b. Nettoyage de votre environnement ▲

delete ENV{qw(IFS CDPATH ENV BASH_ENV)}; # Rend %ENV plus sûr

# Ouverture magique ---peut être n'importe quoi 
open(HF, $fichier) or die "open $fichier magique, impossible : $!"; 

# Garantit l'ouverture d'un fichier en lecture seule et non un pipe 
# ou un fork, mais interprète toujours les descripteurs de 
# fichiers et « - » et ignore les espaces aux extrémités du nom. 
open(HF, "< $fichier") or die "open $fichier, impossible : $!"; 

# Ouverture WYSIWYG : désactive toutes les fonctionnalités accommodantes. 
open(HF, "<", $fichier) or die "open $fichier, impossible : $!"; 

# Mêmes propriétés que la version à 3 arguments WYSIWYG. 
require Fcntl; 
sysopen(HF, $fichier, O_RDONLY) or die "sysopen $fichier, impossible : $!";

23-1-c. Accès aux commandes et aux fichiers avec des privilèges restreints ▲

use English;  # pour employer $UID, etc. 
die "open fork impossible : $!"
    unless defined ($pid = open(DEPUIS_FILS, "-|")); 
if ($pid) {  # père
    while (<DEPUIS_FILS>) {
        # faire quelque chose 
    }
    close DEPUIS_FILS; 
} else {
    $EUID = $UID; # setuid(getuid())
    $EGID = $GID; # setgid(getgid()) et initgroups(2) sur getgroups(2)
    chdir("/")   or die "chdir à / impossible : $!";
    umask(077);
    $ENV{PATH} = "/bin:/usr/bin";
    exec 'mon_prog', 'arg1', 'arg2';
    die "exec mon_prog impossible : $!"; 
}

open(DEPUIS_FILS, "-|") or exec("mon_prog", "arg1", "arg2")
    or die "impossible de lancer mon_prog : $!";

open(DEPUIS_FILS, "-|", "mon_prog", "arg1", "arg2");

use English;

defined( $pid = open( ECRIVAIN_SUR, "|-" ) )
  or die "fork impossible : $!";
if ($pid) {

    # Vous êtes dans le père.
    # Écrivez les données au fils ECRIVAIN_SUR.
    print ECRIVAIN_SUR "donnes_en_sortie\n";
    close ECRIVAIN_SUR
        or die $! ? "Erreur système en fermant ECRIVAIN_SUR : $!"
                  : "Statut d'attente $? depuis ECRIVAIN_SUR";
} else {
    # Vous êtes dans le fils.
    # Abandonnez donc vos privilèges supplémentaires.
    ( $EUID, $EGID ) = ( $UID, $GID );

    # Ouvrez le fichier avec les droits de l'utilisateur original.
    open( HF, ">/un/chemin/de/fichier" 
        or die "open /un/chemin/de/fichier en écriture, impossible : $!" );

    # Copiez depuis le père (maintenant stdin) vers le fichier.
    while (<STDIN>) {
        print HF, $_;
    }
    close(HF) or die "Échec de close : $!";
    exit;    # N'oubliez pas de faire disparaître ECRIVAIN_SUR.
}

Parfois, le comportement de vos programmes est très sensible à la synchronisation d'événements extérieurs hors de votre contrôle. Il s'agit toujours d'un problème lorsque d'autres programmes, particulièrement ceux qui sont inamicaux, pourraient se battre avec votre programme pour les mêmes ressources (comme des fichiers ou des périphériques). Dans un environnement multitâche, vous ne pouvez pas prédire l'ordre dans lequel les processus en attente d'activation vont être autorisés à accéder au processeur. Les flux d'instructions parmi tous les processus éligibles s'entrecroisent, ainsi un processus dispose tout d'abord d'un peu de CPU, ensuite un autre, et ainsi de suite. Il semble aléatoire de savoir celui dont c'est le tour d'être actif et combien de temps il sera autorisé à l'être. Avec un seul programme, il n'y a pas de problème, mais avec plusieurs, partageant des ressources communes, cela peut en être un.

Les programmeurs de « threads » sont particulièrement sensibles à ces questions. Ils apprennent vite à ne plus écrire :

$var++ if $var == 0;

lorsqu'ils veulent dire :

{
    lock($var);
    $var++ if $var == 0; 
}

Le premier exemple donne des résultats imprévisibles lorsque plusieurs threads d'exécution tentent de lancer ce code en même temps. (Voir le chapitre 17, Threads.) Si vous pensez aux fichiers comme à des objets partagés et aux processus comme à des threads candidats pour l'accès à ces objets partagés, vous pourrez voir comment les mêmes questions sont soulevées. Un processus, après tout, n'est en réalité qu'un thread qui s'y croit. Ou vice versa.

L'imprévisibilité des synchronisations affecte à la fois les situations privilégiées et celles qui ne le sont pas. Nous décrirons tout d'abord comment se débrouiller avec un bogue de longue date dans les anciens noyaux Unix affectant tous les programmes set-id. Nous irons ensuite discuter des situations de concurrence en général, comment elles se transforment en brèches de sécurité et les étapes que vous devez suivre pour éviter de tomber dans ces trous.

23-2-a. Bogues de sécurité du noyau Unix ▲

#define VRAI_FICHIER "/chemin/du/script" 
main(ac, av)
    char **av;
{
    execv(VRAI_FICHIER, av); 
}

23-2-b. Gestion des situations de concurrence ▲

if ( -e $fichier ) {
    open( HF, "< $fichier" ) 
        or die "impossible d'ouvrir $fichier en lecture : $!";
}
else {
    open( HF, "> $fichier" )
        or die "impossible d'ouvrir $fichier en écriture : $!";
}

use Fcntl qw/O_WRONLY O_CREAT O_EXCL/; 
open (HF, "<", $fichier)
    or sysopen(HF, $fichier, O_WRONLY | O_CREAT | O_EXCL)
    or die "impossible de créer le nouveau fichier $fichier : $!";

23-2-c. Fichiers temporaires▲

open(TMP, ">/tmp/truc.$$")
    or die "impossible d'ouvrir /tmp/truc.$$ : $!";

# Essaie des noms jusqu'à en obtenir un qui soit tout neuf 
use POSIX; 
do {
    $nom = tmpnam(); 
} until sysopen(TMP, $nom, O_RDWR | O_CREAT | O_EXCL, 0600); 
# Maintenant faites des E/S en utilisant le handle TMP.

# Ou sinon laissez le module le faire à votre place. 
use IO::File; 
my $hf = IO::File::new_tmpfile();    # Il s'agit de tmpfile(3) de POSIX 
# Maintenant faites des E/S en utilisant le handle $hf.

use File::Temp "tempfile"; 
$handle = tempfile();

use File::Temp "tempfile"; 
($handle, $nom_fichier) = tempfile("priseXXXXXX",
                                   DIR => "/var/spool/aventure",
                                   SUFFIX = '.dat');

$nom_virtuel = "/dev/fd" . fileno(TMP);

$nom_virtuel = "=&" . fileno(TMP);

La vérification de marquage n'est qu'une sorte de couverture de survie dont vous avez besoin si vous voulez débusquer des données fausses que vous auriez dû déceler vous-même, mais que vous n'avez pas pu dépister avant de les abandonner au système. C'est un peu comme les avertissements optionnels que Perl peut vous donner — ils peuvent ne pas indiquer de problème réel, mais en moyenne le mal que l'on se donne à gérer les fausses alertes est moindre que celui de ne pas détecter les vrais problèmes. Avec le marquage, ce dernier mal est encore plus insistant, car l'utilisation de données fausses ne donne pas seulement les mauvaises réponses ; cela peut saccager votre système et vos deux dernières années de travail avec. (Et peut-être vos deux prochaines si vous n'avez pas fait de bonnes sauvegardes.) Le mode de marquage est utile lorsqu'il s'agit d'avoir confiance en vous-même pour écrire du code honnête, mais ne que vous ne faites pas systématiquement confiance à quiconque vous passe des données pour ne pas essayer de vous pousser à faire quelque chose de regrettable.

Les données sont une chose. Mais c'est tout à fait une autre affaire lorsque vous ne pouvez même pas faire confiance au code que vous êtes en train d'exécuter. Et si l'applet que vous avez récupérée sur le Net contenait un virus, une bombe à retardement ou un cheval de Troie ? La vérification de marquage est ici inutile, car, alors que les données qui sont fournies au programme peuvent être très bien, c'est le code qui est indigne de confiance. Vous vous mettez dans la situation de quelqu'un qui reçoit un appareil mystérieux de la part d'un étranger, avec une note disant en substance : « Placez ceci contre votre crâne et appuyez sur la détente. » Vous pouvez penser que cela va sécher vos cheveux, mais peut-être plus pour très longtemps.

Dans ce domaine, la prudence est synonyme de paranoïa. Il vous faut un système qui vous permette de placer le code suspect en quarantaine. Il peut continuer à exister et même accomplir certaines fonctions, mais vous ne le laissez pas se promener et faire tout ce dont il a envie. En Perl, vous pouvez imposer un genre de quarantaine en utilisant le module Safe.

23-3-a. Compartiments sécurisés ▲

use Safe; 
my $salle = Safe->new("Donjon"); 
$Donjon::truc = 1; # Pourtant, l'accès direct est déconseillé.

use Safe; 
$Donjon::truc = 1; # L'accès direct est toujours déconseillé. 
my $salle = Safe->new("Donjon");

use Safe; 
my $salle = Safe->new(); 
$salle->reval('$truc = 1');

$salle->reval('$truc++; print "truc vaut maintenant $main::truc\n"'); 
if ($@) {
    die "Impossible de compiler le code dans le compartiment : $@"; 
}

$salle->reval(q{
    our $truc; 
    sub affiche_truc {
        print "truc vaut maintenant $main::truc\n"; 
    }
    }, 1); 
die if $@; # vérification de la compilation

$salle->reval('affiche_truc()');    # Meilleure façon. 
die if $@; 
$salle->varglob('affiche_truc')->(); # Appel via un glob anonyme. 
Donjon::affiche_truc();             # Appel direct, fortement déconseillé.

#!/usr/bin/perl -lTw 
use strict; 
use CGI::Carp 'fatalsToBrowser'; 
use CGI qw/:standard escapeHTML/; 
use Safe;

print header(-type => "text/html;charset=UTF-8"),
   start_html("Résultat de l'expression Perl"); 
my $expr = param("EXPR") =~ /^([^;]+)/
            ? $1 # renvoie la portion maintenant nettoyée
            : croak("aucun champ EXPR valide dans le formulaire"); 
my $reponse = Safe->new->reval($expr); 
die if $@;

print p("Le résultat de", tt(escapeHTML($expr)),
                     "est", tt(escapeHTML($reponse)));

#!/usr/bin/perl -w 
# calcsécu -programme de démonstration pour jouer avec Safe 
use strict; 
use Safe; 
my $salle = Safe->new(); 
while (1) {
    print "Entrée : ";
    my $expr = <STDIN>;
    exit unless defined $expr;
    chomp($expr);
    print "$expr donne ";
    local $SIG{__WARN__} = sub { die @_ };
    my $result = $salle->reval($expr, 1);
    if ($@ =~ s/at \(eval \d+\).*//) {
        printf "[%s]: %s", $@ =~ /trapped by operation mask/
            ? "Violation de la sécurité" : "Exception", $@;
    } else {
        print "[Résultat normal] $result\n"; 
    } 
}

$nouveau = $ancien;      # pas besoin de guillemets ou d'apostrophes. 
print "$nouveau items\n";     # $nouveau ne peut pas vous faire de mal. 

$phrase = "$nouveau items\n"; # ici non plus. 
print $phrase;           # toujours parfaitement OK.

$phrase = "Vous avez perdu @{[ 1 + int rand(6) ]} points\n";

$compteur = '1 + int rand(6)';        # Du code aléatoire. 
$dire     = "$compteur points";       # Plutôt un littéral. 
$dire     = "@{[$compteur]} points";  # Également un littéral.

$code = '1 + int rand(6)'; 
$lance_de_des = eval $code; 
die if $@;

$cmpt =$n= 0; 
while ($donne =~ /( \d+ (?{ $n++ }) | \w+ )/gx) {
    $cmpt++; 
} 
print "$cmpt mots trouvés, dont $n nombres.\n";

if (not eval { "" =~ /$corresp/; 1 }) {
    # (Maintenant faites ce que vous voulez avec un mauvais motif.) 
} else { 
    # Nous savons que le motif est au moins sécurisé pour la compilation.
    if ($donnee =~ /$corresp/) {...}
}

La plus grande étourderie est d'oublier d'utiliser use warnings, qui relève de nombreuses erreurs. La deuxième est de ne pas utiliser use strict quand il le faut. Ces deux pragmas peuvent vous économiser des heures de casse-tête lorsque votre programme commence à grossir. (Et ce sera le cas.) Un autre faux pas consiste à oublier de consulter la FAQ en ligne. Imaginez que vous vouliez trouver si Perl dispose d'une fonction round. Vous devriez essayer de chercher d'abord dans la FAQ :

% perlfaq round

À part ces « métaétourderies », il y a plusieurs types de pièges de programmation. Certains pièges dans lesquels presque tout le monde tombe et d'autres dans lesquels vous ne tombez que si vous êtes originaire d'une culture particulière possédant des pratiques différentes. Nous les avons répartis dans les sections suivantes.

• Mettre une virgule après le handle de fichier dans une instruction print. Bien qu'il paraisse tout à fait rationnel et élégant d'écrire :

print STDOUT, "adieu, monde ", $adj, " !\n"; # MAUVAIS

c'est néanmoins incorrect, à cause de la première virgule. Ce qu'il faut à la place est la syntaxe d'objet indirect :

print STDOUT "adieu, monde ", $adj, " !\n";  # OK

La syntaxe est ainsi faite que l'on puisse écrire :

print $handle_fichier "adieu, monde ", $adj, " !\n";

où $handle_fichier est un scalaire contenant le nom d'un handle de fichier à l'exécution. Ce qui est différent de :

print $pas_un_handle_fichier, "adieu, monde ", $adj, " !\n";

où $pas_un_handle_fichier n'est qu'une chaîne qui est ajoutée à la liste de ce qui

doit être imprimé. Voir « objet indirect » dans le glossaire.

• Utiliser == au lieu de eq et != au lieu de ne. Les opérateurs == et != sont des tests numériques. Les deux autres sont des tests sur les chaînes. Les chaînes "123" et "123.00" sont égales en tant que nombres, mais pas en tant que chaînes. De même, les chaînes non numériques sont numériquement égales à zéro. À moins que vous ne traitiez des nombres, vous utilisez presque toujours à la place les opérateurs de comparaison de chaînes.
• Oublier le point-virgule final. Chaque instruction Perl est terminée par un point-virgule ou la fin d'un bloc. Les sauts de ligne ne sont pas des terminateurs d'instruction comme en awk, en Python ou en FORTRAN. Souvenez-vous que Perl est comme C.
  Une instruction contenant un document « ici-même » (here document) est tout particulièrement apte à perdre son point-virgule. Cela devrait ressembler à ceci :

print <<'FINIS'; 
Sans une grande roideur et une continuelle 
attention à toutes ses paroles, on est exposé à 
dire en moins d'une heure le oui et le non sur une 
même chose ou sur une même personne, déterminé 
seulement par un esprit de société et de commerce 
qui entraîne naturellement à ne pas contredire 
celui-ci et celui-là qui en parlent différemment.

                                   -- Jean de La Bruyère 
FINIS

• Oublier qu'un BLOC exige des accolades. Les instructions seules ne forment pas de BLOC par elles-mêmes. Si vous créez une structure de contrôle comme un while ou un if qui demande un ou plusieurs BLOC s, vous devez utiliser des accolades autour de chaque BLOC. Souvenez-vous que Perl n'est comme C.
• Ne pas sauver $1, $2, etc., dans les expressions régulières. Souvenez-vous que chaque nouvelle correspondance (m//) ou substitution (s///) modifie (ou remet à zéro ou écrase) vos variables $1, $2. . . , ainsi que $`, $&, $' et consorts. Une manière de les sauvegarder consiste à évaluer la correspondance dans un contexte de liste, comme dans :
  my ($un, $deux) = /(\w+) (\w+)/;
• Ne pas se rendre compte qu'un local change aussi la valeur de la variable telle que la voient les autres sous-programmes appelés depuis l'intérieur de la portée du local. Il est facile d'oublier que local est une instruction d'exécution qui travaille dans une portée dynamique, car il n'en existe aucun équivalent dans des langages comme C. Voir la section Déclarations avec portée au chapitre 4, Instructions et déclarations. De toute façon, il est en général préférable d'utiliser un my.
• Perdre la trace des appariements d'accolades. Un bon éditeur vous aidera à trouver les paires correspondantes. Prenez-en un. (Ou deux.)
• Employer des instructions de contrôle de boucle dans un do {} while. Bien que les accolades dans cette structure de contrôle ont l'air de faire partie d'un BLOC de boucle, ce n'est en fait pas le cas.
• Utiliser $truc[1] alors que vous voulez dire $truc[0]. Les tableaux commencent par défaut à zéro en Perl.
• Écrire @truc[0] alors que vous vouliez dire $truc[0]. La référence à @truc[0] est une tranche de tableau, représentant un tableau constitué du seul élément $truc[0]. Parfois, cela ne fait aucune différence, comme dans : print "la réponse est @truc[0]\n";
  Mais la différence est énorme pour des choses comme :
  @truc[0] = <STDIN>; qui va absorber tout STDIN en affectant la première ligne à $truc[0] et en rejetant tout le reste, ce qui n'est probablement pas ce que vous aviez prévu. Prenez l'habitude de considérer que $ représente une valeur unique, alors que @ représente une liste de valeurs, et tout ira bien.
• Oublier les parenthèses avec un opérateur de liste comme my : my$x,$y =(4, 8);#FAUXmy ($x, $y) = (4, 8); # OK
• Oublier de sélectionner le bon handle de fichier avant de positionner $^, $~ ou $|. Ces variables dépendent du handle de fichier actuellement sélectionné, comme le détermine select (HANDLE_FICHIER). Le handle de fichier initialement sélectionné est STDOUT. Vous devriez vraiment plutôt utiliser les méthodes de handles de fichiers du module FileHandle. Voir le chapitre 28, Noms spéciaux.

24-2-a. Conseils fréquemment ignorés ▲

($x) = (4, 5, 6);        # Contexte de liste ; 
$x vaut 4 $x=(4,5,6);    # Co escalaire;$x vaut 6

@a = (4, 5, 6);
$x = @a;                 # Contexte scalaire ; $x vaut 3
                         # (la longueur du tableau)

print <HF> "salut"; # MAUVAIS, omettre les angles

while (<HF>) { }   # Données affectées à $_. 
<HF>;              # données lues et éliminées !

$x =  /truc/;      # recherche "truc" dans $_, met le résultat dans $x $x =~ /truc/;      # recherche "truc" dans $x, élimine le résultat

24-2-b. Pièges du C ▲

if (expression) {
    bloc; 
} 
else if (autre_expression) { # MAUVAIS
    autre_bloc; 
}

if (expression) {
    bloc;
} elsif (autre_expression) {
    autre_bloc; 
}

24-2-c. Pièges du shell ▲

chameau='dromadaire';   # MAUVAIS

$chameau='dromadaire'; # OK

foreach bosse (une deux)
    remplir $bosse 
end

foreach $bosse ("une", "deux") {
    remplir($bosse); 
}

chop($mon_hote = `hostname`);

24-2-d. Pièges des anciens Perl ▲

sub Ciao { die "Hasta la vista, baby !" } 
$SIG{'QUIT'} = Ciao;

print "$a::$b::$c\n"

print "$var::abc::xyz\n";

Shift @liste + 20; # maintenant analysé comme shift(@liste + 20), 
                   # illégal ! 
$n = keys %map + 20; # maintenant analysé comme keys(%map + 20), 
                     # illégal !

sleep $sieste + 20;

/truc/ ? ($a += 2) : ($a -= 2);

/truc/?$a+= 2 : $a -= 2;

(/truc/ ? $a +=2 : $a) -= 2;

$a+= /truc/ ? 1 : 2;

% perl4 -e '@a = (1,2,3); for (grep(/./, @a)) { $_++ }; print "@a\n"' 1 2 3 
% perl5 -e '@a = (1,2,3); for (grep(/./, @a)) { $_++ }; print "@a\n"' 
2 3 4

foreach $var (grep /x/, @liste) { ... }

foreach $var (my @tmp = grep /x/, @list) { ... }

Alors que l'essentiel du travail de programmation peut se résumer à un fonctionnement correct, vous pouvez vous retrouver à vouloir parfois un meilleur rapport qualité/prix pour votre programme Perl. Le vaste ensemble d'opérateurs, les types de données et les structures de contrôle de Perl ne sont pas forcément intuitifs quant à la rapidité d'exécution et à l'optimisation de l'espace mémoire. De nombreux compromis ont été nécessaires pendant la conception de Perl et ces décisions sont profondément ancrées dans les entrailles du code. En général, plus un programme est court et simple, plus il est rapide, mais il existe des exceptions. Ce paragraphe tente de vous aider à le faire fonctionner juste un petit peu mieux.

Si vous voulez qu'il tourne beaucoup mieux, vous pouvez jouer avec la sortie (backend) du compilateur de Perl, décrite au chapitre 18, Compiler ou réécrire votre boucle interne dans une extension C, comme l'illustre le chapitre 21, Mécanismes internes et externes.

Vous remarquerez que l'optimisation de la vitesse d'exécution est parfois coûteuse en termes d'espace mémoire ou d'efficacité pour le programmeur (on s'en rend compte en constatant que certaines des astuces ci-dessous sont incompatibles entre elles). Voilà le hic. Si la programmation était si simple, il n'y aurait pas besoin de quelque chose d'aussi compliqué qu'un être humain pour s'en occuper, n'est-ce pas?

24-3-a. Efficacité du temps d'exécution ▲

my %mots_cles; 
for (@mots_cles) {
    $mots_cles{$_}++; 
}

$mots_cles{$_}

no strict 'refs'; 
$nom = "variable"; 
$$nom = 7;  # Positionne $variable à 7

"chaine_trouvee" =~ /$motif_courant/; # Correspondance bidon
                                     # (doit réussir). 
while (<>) {
    print if //; 
}

print if /une-bosse/ || /deux/;

print if /une-bosse|deux/;

while (<>) {
    next if /^#/;
    next if /^$/;
    chop; 
    @gorets = split(/,/);
    ... 
}

while ($tampon) {
    traiter(substr($tampon, 0, 10, "")); 
}

$truc = substr($truc,0,3) . $machin . substr($truc,7);

substr($truc, 3, 4) = $machin;

if ($a) {
    $truc = $a; 
} 
elsif ($b) {
    $truc = $b; 
} 
elsif ($c) {
    $truc = $c; 
}

$pi ||= 3;

print $nom_complet{$nom} . " a un nouveau répertoire home " .
    $home{$nom} . "\n";

print $nom_complet{$nom}, " a un nouveau répertoire home ",
    $home{$nom}, "\n";

sub numennom {
    local($_) = @_;
    unless (defined $num_en_nom{$_}) {
        my(@a) = gethostbyaddr(pack('C4', split(/\./)), 2);
        $num_en_nom{$_} = @a > 0 ? $a[0] : $_; 
    }
    return $num_en_nom{$_}; 
}

chmod +t /usr/bin/perl

24-3-b. Efficacité de l'espace mémoire ▲

24-3-c. Efficacité pour le programmeur ▲

24-3-d. Efficacité pour le mainteneur ▲

24-3-e. Efficacité pour le porteur ▲

24-3-f. Efficacité pour l'utilisateur ▲

open(FICHIER, $fichier)
    or die "$0: Ouverture de $fichier en lecture impossible : $!\n";

Vous aurez certainement vos propres préférences en matière de formatage, mais quelques lignes de conduite rendront vos programmes plus faciles à lire, à comprendre et à maintenir.

Le plus important est de toujours lancer vos programmes sous le pragma use warnings. (Vous pouvez désactiver les avertissements dont vous ne voulez pas avec no warnings.) Vous devriez également tourner sous le pragma use strict ou avoir une bonne excuse pour ne pas le faire. Le pragma use sigtrap et même use diagnostics peuvent aussi être bénéfiques.

Quant à l'esthétique du code, la seule chose à laquelle Larry prête une certaine importance est que l'accolade fermante d'un BLOC multiligne devrait se trouver sur la même colonne que le mot-clef qui a commencé la construction. Par ailleurs, il a d'autres préférences qui ne sont pas si impératives. Les exemples de ce livre respectent ces conventions (ou du moins le devraient) :

• Indentation sur 4 colonnes.
• Une accolade ouvrante doit se trouver sur la même ligne que le mot-clef qui la précède, si possible ; sinon, il faut les aligner verticalement.

while ($condition) {    # ici, court : sur la même ligne
    # faire quelque chose 
}

# si la condition déborde, aligner les accolades 
# l'une au-dessus de l'autre. 
while ($une_condition and $autre_condition
       and $encore_une_longue_condition) 
{
    # faire quelque chose 
}

• Mettez un espace avant l'accolade ouvrante d'un BLOC multiligne.
• Un BLOC court peut être mis sur une seule ligne, accolades comprises.
• Omettez le point-virgule dans un BLOC court d'une seule ligne.
• Entourez la plupart des opérateurs avec des espaces.
• Entourez un indice « complexe » (à l'intérieur de crochets) par des espaces.
• Mettez des lignes blanches entre les morceaux de code qui font des choses différentes.
• Mettez un saut de ligne entre une accolade fermante et else.
• Ne mettez pas d'espace entre un nom de fonction et sa parenthèse ouvrante.
• Ne mettez pas d'espace avant un point-virgule.
• Mettez un espace après chaque virgule.
• Divisez les longues lignes après un opérateur (mais avant and et or, même lorsqu'ils s'écrivent && et ||).
• Alignez verticalement les items correspondants.
• Omettez les ponctuations redondantes tant que la clarté n'en souffre pas.
• Larry a ses raisons concernant chacun de ces points, mais il ne prétend pas que le cerveau de tout le monde fonctionne (ou ne fonctionne pas) comme le sien. Voici d'autres questions de style plus substantielles, qui donnent matière à réflexion :
• Ce n'est pas parce que vous pouvez faire quelque chose d'une certaine manière que vous devez le faire ainsi. Perl est conçu pour fournir plusieurs façons de faire tout ce que l'on veut, il convient donc de choisir la plus lisible. Par exemple :

open(TRUC,$truc) or die "ouverture de $truc impossible : $!";

vaut mieux que

die "Ouverture de $truc impossible : $!" unless open(TRUC,$truc);

car la deuxième manière cache l'essentiel de l'instruction dans un modificateur. À l'inverse,

print "Début de l'analyse\n" if $verbeux;

vaut mieux que

$verbeux and print "Début de l'analyse\n";

puisque l'essentiel n'est pas de savoir si l'utilisateur a ou non tapé -v.

• De même, ce n'est pas parce qu'un opérateur vous permet d'utiliser des arguments par défaut que vous devez en faire usage. Ils sont réservés aux programmeurs paresseux qui écrivent des scripts vite fait, ne servant qu'une fois. Si vous voulez que vos programmes soient lisibles, pensez à fournir les arguments.
• Dans la même lignée, ce n'est pas parce que vous pouvez omettre les parenthèses dans de nombreux cas que vous devez le faire :

return print reverse sort num values %hachage; 
return print(reverse(sort num (values(%hachage))));

En cas de doute, mettez des parenthèses. Au pire, cela permettra aux pauvres idiots

de taper sur la touche % dans vi. Même si vous n'avez aucun doute, imaginez l'état mental de la personne qui devra maintenir le code après vous et qui mettra probablement des parenthèses au mauvais endroit.

• Ne vous livrez pas à un exercice stupide de contorsionniste pour sortir en haut ou en bas d'une boucle. Perl fournit l'opérateur last qui vous permet d'en sortir au milieu. Vous pouvez optionnellement l'« exdenter » un peu pour le rendre plus visible :

LIGNE:
    for (;;) \{
        instructions;
    last LIGNE if $machin;
        next LIGNE if /^#/;
        instructions;
    }

• N'ayez pas peur d'utiliser des étiquettes de boucles — elles sont là tant pour améliorer la lisibilité que pour permettre les ruptures de boucles sur plusieurs niveaux. Voir l'exemple précédent.
• Évitez d'utiliser grep, map ou les apostrophes inverses dans un contexte vide, c'est-à-dire lorsque vous ne vous occupez pas des valeurs de retour. Ces fonctions ont toutes des valeurs de retour, qui ne demandent qu'à être utilisées. Sinon, employez une boucle foreach ou la fonction system.
• Dans un but de portabilité, quand vous employez des fonctionnalités qui peuvent ne pas être implémentées sur toutes les machines, testez-les dans un eval pour savoir si elles échouent. Si vous connaissez la version ou le patch level (N.d.T. Niveau de correction) d'une fonctionnalité particulière, vous pouvez tester $] ($PERL_VERSION avec le module English) pour savoir si telle fonctionnalité est présente. Le module Config permet également de retrouver les valeurs déterminées par le programme Configure quand Perl a été installé.
• Choisissez des identificateurs mnémoniques. Si vous ne vous souvenez pas de la signification du terme mnémonique, il y a un problème.
• Alors que des identificateurs courts comme $reussi conviennent souvent parfaitement, employez des soulignés pour séparer les mots. Il est généralement plus facile de lire un $nom_de_variable_comme_ceci qu'un $NomDeVariableCommeCeci, surtout pour des lecteurs dont la langue d'origine n'est pas l'anglais. Même chose pour $NOM_DE_VARIABLE_COMME_CECI.
• Les noms des paquetages représentent parfois une exception à cette règle. Perl réserve de façon informelle les noms en minuscule pour des modules de pragmas comme integer et strict. Les autres modules devraient commencer par une majuscule et mélanger les casses, mais de préférence sans caractère souligné en raison des restrictions de nommage de certains systèmes de fichiers primitifs.
• Il peut s'avérer utile d'utiliser les casses de caractères pour indiquer la visibilité ou la nature d'une variable. Par exemple :

$TOUT_EN_MAJUSCULES    # constantes uniquement (attention aux
                       # conflits avec les vars de Perl!)
$Quelques_Majuscules   # vars globales/statiques sur tout un paquetage 
$pas_de_majuscules     # vars my() ou local(), dont la portée ne
                       #dépasse pas une fonction

Pour diverses raisons plutôt vagues, les noms de méthodes et de fonctions semblent plus lisibles lorsqu'ils sont entièrement en minuscules. Par exemple, $obj->en_chaine().

Vous pouvez faire précéder le nom d'un caractère souligné pour indiquer qu'une variable ou une fonction ne devrait pas être utilisée hors du paquetage qui l'a définie. (Perl ne force pas ceci ; ce n'est qu'une forme de documentation.)

• Dans le cas d'une expression régulière réellement inextricable, utilisez le modificateur /x et insérez des espaces pour améliorer le rapport signal/bruit.
• N'employez pas de slash comme délimiteurs lorsque votre expression en comporte déjà trop ou contient trop d'antislashs.
• N'utilisez pas les apostrophes ou les guillemets comme délimiteurs lorsque votre chaîne en contient déjà. Utilisez plutôt les pseudofonctions q//, qq// ou qx//.
• Utilisez les opérateurs and et or pour éviter de mettre trop de parenthèses autour des opérateurs de liste, et pour réduire l'incidence des opérateurs de ponctuation comme && et ||. Appelez vos sous-programmes comme s'il s'agissait de fonctions ou d'opérateurs de liste afin d'éviter un excès d'esperluettes et de parenthèses.
• Utilisez des documents « ici-même » (here documents) au lieu d'instructions print répétées.
• Alignez verticalement les choses correspondantes, surtout si elles sont trop longues pour tenir sur une ligne :

$IDX = $ST_MTIME; 
$IDX = $ST_ATIME      if $opt_u; 
$IDX = $ST_CTIME      if $opt_c; 
$IDX = $ST_SIZE       if $opt_s; 

mkdir $rep_tmp, 0700 or die "mkdir $rep_tmp impossible : $!"; chdir($rep_tmp)     or die "chdir $rep_tmp impossible : $!"; 
mkdir 'tmp',    0777 or die "mkdir $rep_tmp/tmp impossible : $!";

• Ce que nous vous répétons trois fois est vrai :

• Les messages d'erreur devaient aller vers STDERR et devraient indiquer de quel programme provient l'erreur, ainsi que l'appel de fonction et les arguments. Le plus important est qu'ils devraient contenir, lorsque les appels système ont échoué, le message d'erreur système standard sur ce qui ne va pas. En voici un exemple simple, mais suffisant :

opendir(R, $rep) or die "opendir $rep impossible : $!";

• Alignez vos traductions si cela a un sens :

tr [abc]
   [xyz];

• Pensez à la réutilisabilité. Pourquoi gâcher votre énergie cérébrale sur des scripts jetables alors que vous êtes susceptible de les réécrire plus tard? Vous pouvez rendre votre code générique. Vous pouvez écrire un module ou une classe d'objets. Vous pouvez faire tourner proprement votre code en activant use strict et -w. Vous pouvez donner votre code aux autres. Vous pouvez changer votre vision globale du monde. Vous pouvez. . . oh et puis tant pis.
• Soyez cohérent.
• Soyez sympa.

Nous avons abordé quelques idiomes dans les paragraphes précédents (pour ne pas citer les chapitres précédents), mais il y en a beaucoup d'autres que vous verrez couramment si vous lisez des programmes réalisés par des programmeurs Perl accomplis. Lorsque nous parlons de Perl idiomatique dans ce contexte, nous ne parlons pas seulement d'un ensemble arbitraire d'expressions Perl au sens figé. Nous parlons plutôt de code Perl montrant une compréhension des méandres du langage, que vous pouvez avaler tel quel sans vous poser de question. Et quand l'avaler.

Nous n'imaginons même pas énumérer tous les idiomes que vous pourriez rencontrer — cela prendrait tout un livre, aussi épais que celui-ci. Et peut-être même deux. (Voir Perl en action, par exemple.) Mais voici quelques idiomes importants, où l'on pourrait définir « important » comme « ce qui incite les persiflages des gens qui pensent déjà savoir comment les langages informatiques devraient fonctionner ».

• Utilisez => en lieu et place d'une virgule partout où vous pensez que cela améliore la lisibilité :

return bless $pagaille => $classe;

Vous devez lire cela comme « Consacrer cette pagaille dans la classe spécifiée. » Faites juste attention à ne pas l'employer après un mot dont vous ne voudriez pas qu'il soit automatiquement mis entre guillemets :

sub truc()  { "TRUC" } 
sub machin() { "MACHIN"} 
print truc => machin;    # affiche trucMACHIN et non TRUCMACHIN.

Un autre endroit approprié à l'emploi de => est à proximité d'une virgule littérale que l'on pourrait confondre visuellement :

join(", " => @tableau);

Perl vous offre plus d'une manière de le faire (N.d.T. There's More Than One Way To Do It, le slogan de Perl) vous pouvez donc faire preuve de créativité. Faites-en preuve !

• Utilisez le pronom singulier pour améliorer la lisibilité :

for (@lignes) {
    $_ .= "\n"; 
}

La variable $_ est la version de Perl d'un pronom et il signifie essentiellement « il ».(180) Ainsi, le code ci-dessus signifie « pour chaque ligne, ajoutez-lui un saut de ligne. » De nos jours, vous pouvez même écrire cela comme :

$_ .= "\n" for @lignes;

Le pronom $_ est tellement important pour Perl qu'il est obligatoire de l'utiliser dans grep et map. Voici un moyen de configurer un cache pour les résultats communs d'une fonction coûteuse :

%cache = map { $_ => couteuse($_) } @args_communs; 
$xval = $cache{$x} || couteuse($x);

• Omettez le pronom pour améliorer encore plus la lisibilité.(181)
  Utilisez des contrôles de boucles avec des modificateurs d'instructions.

while (<>) {
    next if /^=pour\s+(index|après)/;
    $cars += length;
    $mots += split;
    $lignes += y/\n//; 
}

Il s'agit d'un extrait de code que nous avons utilisé pour compter les pages de ce livre. Lorsque vous vous apprêtez à travailler souvent avec la même variable, il est souvent plus lisible de laisser complètement tomber les pronoms, contrairement à la croyance populaire.

Cet extrait démontre également l'utilisation idiomatique de next avec un modificateur d'instruction pour court-circuiter une boucle. La variable $_ est toujours la variable de contrôle de boucle dans grep et, map mais la référence du programme pointant dessus est souvent implicite :

$longueur_hachage = grep { length } @aleatoire;

Nous prenons ici une liste de scalaires aléatoires et ne choisissons que ceux qui ont une longueur supérieure à 0.

• Utilisez for pour positionner l'antécédent d'un pronom :

for ($episode) {
    s/fred/barney/g;
    s/wilma/betty/g;
    s/pebbles/bambam/g; 
}

Mais que se passe-t-il s'il n'y a qu'un seul élément dans la boucle ? Il s'agit d'un moyen pratique de positionner « le », c'est-à-dire $_. En linguistique, cela s'appelle une topicalisation. Ce n'est pas de la triche, c'est de la communication.

• Référencez implicitement le pronom pluriel, @_.
• Utilisez les opérateurs de contrôle de f lux pour fixer les valeurs par défaut :

sub aboyer {
    my Chien $medor = shift;
    my $qualite = shift || "jappant";
    my $quantite = shift || "sans_arrêt";
    ... 
}

Nous avons employé ici l'autre pronom de perl, @_, qui signifie « eux ».(182) Les arguments d'une fonction arrivent toujours comme « eux ». L'opérateur shift sait qu'il doit travailler sur @_ si vous l'omettez, tout comme l'employé de Disneyland crierait « Au suivant ! » sans préciser quelle file d'attente est supposée avancer. (Il n'y a pas lieu de spécifier, car il n'y a qu'une seule queue qui importe.) Le || peut être utilisé pour fixer les valeurs par défaut malgré ses origines d'opérateur booléen, puisque Perl renvoie la première valeur qui soit vraie. Les programmeurs Perl font souvent preuve d'une attitude assez cavalière avec la vérité ; la ligne ci-dessus ne fonctionnerait pas si, par exemple, vous essayiez de spécifier une quantité nulle. Mais tant que vous ne voulez jamais positionner $qualite ou $quantite à une valeur fausse, l'idiome marche parfaitement. Il n'y a pas lieu de devenir superstitieux et de lancer partout des appels à defined et exists. Tant que la valeur ne devient pas accidentellement fausse, tout ira bien.

• Utilisez les formes d'affectation des opérateurs, y compris les opérateurs de contrôle de flux :

$xval = $cache{$x} ||= couteuse($x);

Ici nous n'initialisons pas du tout notre cache. Nous ne faisons que nous reposer sur l'opérateur ||= pour appeler couteuse($x) et ne l'affecter à $cache{$x} que si $cache{$x} est faux. Le résultat de ceci est la nouvelle valeur de $cache{$x} quelle qu'elle soit. Encore une fois, nous avons adopté une approche quelque peu cavalière de la vérité, en ce que si nous mettons en cache une valeur fausse, couteuse($x) sera à nouveau appelée. Le programmeur sait peut-être que cela fonctionne, car couteuse{$x} n'est pas coûteuse lorsqu'elle renvoie une valeur fausse. Ou peut-être que le programmeur a simplement tendance à bâcler son travail. Ce qui peut être analysé comme une forme de créativité.

• Utilisez les contrôles de boucles en tant qu'opérateurs, pas seulement en tant qu'instructions. Et. . .
• Utilisez les virgules comme de petits points-virgules :

while (<>) { 
    $commentaires++, next if /^#/;
    $blancs++, next       if /^\s*$/; 
    last                  if /^__END__/;
    $code++; 
} 
print "commentaires = $commentaires\nblancs = $blancs\ncode = $code\n";

Ceci montre que nous comprenons que les modificateurs d'instructions modifient les instructions, alors que next est un simple opérateur. Cela montre également que la virgule, lorsqu'elle est utilisée de façon idiomatique pour séparer les expressions, exactement comme vous le feriez avec un point-virgule. (La différence est que la virgule garde les deux expressions comme faisant partie de la même instruction, sous le contrôle de l'unique modificateur d'instruction.)

• Utilisez le contrôle de flux à votre avantage :

while (<>) { 
    /^#/          and $commentaires++; 
    /^s*$/        and $blancs++;
    /^__END__/    and last;
    $code++; 
}
print "commentaires = $commentaires\nblancs = $blancs\ncode = $code\n";

Il s'agit exactement de la même boucle, seulement cette fois-ci, les motifs sont au début. Le programmeur Perl perspicace comprend que la compilation donne exactement le même code interne que l'exemple précédent. Le modificateur if n'est qu'une conjonction and (ou &&) inversée et le modificateur unless est une conjonction or (ou ||) inversée.

• Utilisez les boucles implicites fournies par les options -n et -p.
• Ne mettez pas de point-virgule à la fin d'un bloc d'une seule ligne :

#!/usr/bin/perl -n 
$commentaires++, next LINE if /^#/; 
$blancs++, next LINE       if /^\s*$/; 
last LINE                  if /^__END__/; 
$code++; 

END { print "commentaires = $commentaires\nblancs = $blancs\ncode = $code\n" }

Il s'agit essentiellement du même programme que précédemment. Nous avons mis une étiquette LINE (LIGNE en anglais) explicite dans les opérateurs de contrôle de boucle parce que nous en avions envie, mais nous n'y étions pas obligés, puisque la boucle LINE implicite, fournie par -n est la boucle encadrante la plus intérieure. Nous avons employé END pour avoir l'instruction print finale à l'extérieur de la boucle principale implicite, exactement comme dans awk.

• Utilisez des documents « ici-même » (here documents) lorsque les affichages deviennent monstrueux.
• Utilisez un délimiteur significatif dans les documents « ici-même » :

END { print <<"COMPTEURS" } commentaires = $commentaires 
blancs = $blancs 
code = $code 
COMPTEURS

Au lieu d'utiliser plusieurs print, le programmeur parlant Perl couramment emploie une chaîne multiligne avec interpolation. Bien que nous ayons appelé ceci une « étourderie courante » auparavant, nous avons effrontément enlevé le point-virgule final, car il n'est pas nécessaire à la fin du bloc END. (Si nous le changeons un jour en bloc multiligne, nous remettrons le point-virgule.)

• Faites des substitutions et des traductions en passant(183) sur un scalaire :

($nouveau = $ancien) =~ s/mauvais/bon/g;

Puisque les lvalues sont lvaluables(184), pour ainsi dire, vous verrez souvent les gens changer une valeur en passant alors qu'elle est en train d'être affectée. Ceci peut en fait éviter une copie de chaîne en interne (si nous arrivons jamais à implémenter l'optimisation) :

chomp($reponse = <STDIN>);

Toute fonction qui modifie un argument sur place peut utiliser l'astuce en passant. Mais attendez, il y a mieux !

• Ne vous limitez pas à modifier les scalaires en passant :

for (@nouveau = @ancien) { s/mauvais/bon/g }

Ici, nous copions @ancien dans @nouveau, en modifiant tout en passant (pas tout d'un coup, bien entendu — le bloc est exécuté de manière répétitive, un « il » (c'est-à-dire $_) à la fois).

• Passez les paramètres nommés en utilisant l'opérateur virgule de fantaisie, =>.
• Fiez-vous à l'affectation à un hachage pour traiter un argument pair/impair :

sub aboyer {
    my Chien $medor = shift;
    my %param = @_
    my $qualite = $param{QUALITE} || "jappant";
    my $quantite = $param{QUANTITE} || "sans_arrêt";
    ... 
} 
$fido->aboyer( QUANTITE => "une_fois",
                QUALITE => "ouaf" );

Les paramètres nommés sont souvent un luxe abordable. Et avec Perl, vous les avez pour rien, si vous ne comptez pas le coût de l'affectation de hachage.

• Répétez les expressions booléennes jusqu'à obtenir une valeur fausse.
• Utilisez les recherches de correspondances minimales lorsqu'elles sont appropriées.
• Utilisez le modificateur /e pour évaluer une expression de remplacement :

#!/usr/bin/perl -p
while s/^(.*)?(\t+)/$1 . ' ' x length($2) *4 -length($1) %4)/e;

Ce programme corrige tout fichier que vous recevez de la part de quelqu'un pensant par erreur qu'il peut redéfinir les tabulations matérielles pour qu'elles occupent 4 espaces au lieu de 8. Il utilise plusieurs idiomes importants. Tout d'abord, l'idiome 1 est commode lorsque tout le travail que vous voulez accomplir dans la boucle est en fait déjà réalisé par la condition. (Perl est assez malin pour ne pas vous avertir que vous êtes en train d'utiliser 1 dans un contexte vide.) Nous devons répéter cette substitution, car chaque fois que nous remplaçons un certain nombre d'espaces par des tabulations, nous devons recalculer depuis le début la colonne où doit se trouver la prochaine tabulation.

Le (.*?) correspond à la plus petite chaîne possible jusqu'à la première tabulation, en utilisant le modificateur de correspondance minimal (le point d'interrogation). Dans ce cas, nous aurions pu utiliser un * gourmand comme d'ordinaire, ainsi : ([^\t]*). Mais cela ne marche que parce qu'une tabulation est un seul caractère, nous avons donc employé une classe de caractères avec une négation pour éviter de dépasser la première tabulation. En général, la correspondance minimale est plus élégante et elle n'échoue pas si la prochaine chose qui doit correspondre fait plus d'un caractère.

Le modificateur /e réalise une substitution en utilisant une expression plutôt qu'une chaîne. Cela nous permet d'effectuer les calculs dont nous avons besoin au moment exact où nous en avons besoin.

• Utilisez une mise en page et des commentaires créatifs pour les substitutions complexes :

#!/usr/bin/perl -p 
while s{
    ^           # attachement au début 
    (           # commence le premier regroupement
         .*?    # correspond au nombre de caractères minimal 
    )           # termine le premier regroupement 
    (           # commence le second regroupement
        \t+     # correspond à une ou plusieurs tabulations 
    )           # termine le second regroupement 
} 
{
    my $lg_espaces = length($2) * 4;    # comptage des tabulations 
                                        # complètes
    $lg_espaces -= length($1) % 4;      # longueur de la tabulation 
                                        # incomplète
    $1 . ' ' x $lg_espaces;             # calcule le nombre d'espaces 
                                        # correct 
}ex;

Nous en faisons probablement un peu trop, mais certaines personnes trouvent cet exemple plus impressionnant que le précédent qui tenait sur une seule ligne. À vous de voir.

Allez de l'avant et utilisez $` si vous le sentez :

while s/(\t+)/' ' x (length($1) * 4 -length($`) % 4)/e;

Il s'agit ici d'une version plus courte, qui utilise $`, bien connu pour son impact sur les performances. Sauf que nous n'utilisons que sa longueur, alors ça ne compte pas vraiment.

Utilisez les décalages directement à partir des tableaux @-(@LAST_MATCH_START) et

@+ (@LAST_MATCH_END): 1 while s/\t+/' ' x (($+[0] -$-[0]) * 4 -$-[0] % 4)/e;

Cet exemple-ci est encore plus court. (Si vous ne voyez pas de tableaux ici, essayez à la place de rechercher des éléments de tableaux.) Voir @- et @+ au chapitre 28.

Utilisez eval avec une valeur de retour constante :

sub est_un_motif_valide {
    my $motif = shift;
    return eval { "" =~ /$motif/; 1 } || 0; 
}

Vous n'avez pas à utiliser l'opérateur eval {} pour renvoyer une valeur réelle. Ici, nous renvoyons toujours 1 si la correspondance parvient à se terminer. Toutefois, si le motif contenu dans $motif explose, l'eval intercepte ceci et renvoie undef à la condition booléenne de l'opérateur ||, qui transforme cela vers la valeur définie 0 (simplement pour être poli, puisque undef est également faux, mais pourrait conduire quelqu'un à penser que la routine est_un_motif_valide s'est mal comportée et nous ne voudrions pas que cela se produise, n'est-ce pas ?).

• Utilisez des modules pour faire le sale boulot.
• Utilisez des usines d'objets.
• Utilisez des fonctions de rappel (callbacks).
• Utilisez des piles pour garder une trace du contexte.
• Utilisez des indices négatifs pour accéder à la fin d'un tableau ou d'une chaîne :

use XML::Parser;
                    
$p = new XML::Parser Style => 'subs'; 
setHandlers $p Char => sub { $sorties[-1] .= $_[1] }; 

push @sorties, "";

sub literal {
    $sorties[-1] .= "C<";
    push @sorties, ""; 
}

sub literal_ {
    my $texte = pop @sorties;
    $sorties[-1] .= $texte . ">"; 
} 
...

Il s'agit d'un court extrait d'un programme de 250 lignes que nous avons utilisé pour retraduire la version XML de l'ancienne édition de ce livre(185) en format pod afin que nous puissions l'ouvrir pour la présente édition dans un Véritable Éditeur de Texte.

La première chose que vous remarquerez est que nous nous appuyons sur le module XML::Parser (de CPAN) pour analyser notre XML correctement, nous n'avons donc pas à comprendre comment le faire. Cela soulage déjà notre programme de quelque milliers de lignes (en supposant que nous réimplémentions en Perl tout ce que XML::Parser accomplit pour nous,(186) y compris la traduction de presque tous les ensembles de caractères vers de l'UTF-8).

XML::Parser utilise un idiome de haut niveau appelé une usine d'objets. Dans ce cas, il s'agit d'une usine d'analyseur. Lorsque nous créons un objet XML::Parser, nous lui disons quel style d'interface d'analyseur nous voulons et il en crée un pour nous. C'est un excellent moyen de construire une plate-forme de test pour une application lorsque vous n'êtes pas sûr de savoir quelle interface sera la meilleure à long terme. Le style subs ne représente qu'une des interfaces de XML::Parser. En fait, il s'agit de l'une des plus anciennes interfaces et probablement pas la plus populaire de nos jours.

La ligne setHandlers montre un appel de méthode sur l'analyseur, pas en notation f léchée, mais dans la notation « d'objet indirect », qui vous permet, entre autres, d'omettre les parenthèses autour des arguments. La ligne utilise également l'idiome des paramètres nommés que nous avons vu plus tôt.

La ligne montre également un autre concept très puissant, la notion de fonction de rappel (callback). Plutôt que d'appeler l'analyseur pour obtenir l'élément suivant, nous lui demandons de nous appeler. Pour les balises XML nommées, comme <literal>, ce style d'interface appellera automatiquement un sous-programme de ce nom (ou le nom avec un souligné à la fin pour la balise fermante correspondante). Mais les données entre les balises n'ont pas de nom, nous configurons donc une fonction de rappel, Char, avec la méthode setHandlers. Ensuite, nous initialisons le tableau @sorties, qui est une pile des affichages. Nous y mettons une chaîne vide pour représenter le fait que nous n'avons collecté aucun texte à ce niveau d'imbrication des balises (0, initialement).
C'est maintenant que réapparaît la fonction de rappel. Dès que nous voyons un texte, il est automatiquement ajouté après l'élément final du tableau, via l'idiome $sortie[-1] dans la fonction de rappel. Au niveau de balise le plus extérieur, $sorties[-1] est équivalent à $sortie[0], $sorties[0] termine donc notre affichage complet. (Éventuellement. Mais nous devons d'abord traiter les balises.)

Supposez que nous voyions une balise <literal>. Alors le sous-programme literal est appelé, ajoute du texte à l'affichage courant, puis pousse un nouveau contexte dans la pile @sorties. Dès lors, tout texte rencontré jusqu'à la balise fermante se voit ajouté à cette nouvelle fin de la pile. Lorsque nous rencontrons la balise fermante, nous dépilons (avec pop) le $texte que nous avons collecté hors de la pile @sorties et nous ajoutons le reste des données métamorphosées à la nouvelle (c'est-à-dire, l'ancienne) fin de la pile, dont le résultat est la traduction de la chaîne XML, <literal>texte</literal>, vers la chaîne pod correspondante, C<texte>.

Les sous-programmes pour les autres programmes sont exactement les mêmes, à part qu'ils sont différents.

• Utilisez my sans affectation pour créer un tableau ou un hachage vide.
• Éclatez la chaîne par défaut selon les espaces qu'elle contient.
• Affectez aux listes de variables pour en collecter autant que vous voulez.
• Utilisez l'autovivification des références indéfinies pour les créer.
• Autoincrémentez les éléments indéfinis de tableau ou de hachage pour les créer.
• Utilisez l'autoincrémentation d'un hachage %vus pour déterminer l'unicité.
• Affectez à une variable temporaire my bien pratique dans la condition.
• Utilisez le comportement de protection automatique des accolades.
• Utilisez un mécanisme de protection alternatif pour interpoler les guillemets.
• Utilisez l'opérateur ?: pour choisir entre deux arguments d'un printf.
• Alignez verticalement les arguments de printf avec leur champ % :

my %vus; 
while (<>) {
    my ($a, $b, $c) = split;
    print unless $vus{$a}{$b}{$c}++; 
} 
if (my $tmp = $vus{nifnif}{nafnaf}{noufnouf}) {
    printf qq("nifnif nafnaf noufnouf" vu %d coup%s\n), 
                                          $tmp, $tmp == 1 ? "" : "s"; 
}

Ces neuf lignes débordent d'idiomes. La première ligne donne un hachage vide, car nous n'y affectons rien. Nous parcourons itérativement les lignes entrées en positionnant « le », c'est-à-dire $_, implicitement, puis nous utilisons un split sans arguments qui « l' » éclate selon les espaces qu'« il » contient. Ensuite nous prenons les trois premiers mots avec une affectation de liste, en rejetant les mots suivants. Puis nous mémorisons les trois premiers mots dans un hachage à trois dimensions, qui créent automatiquement (si nécessaire) les deux premiers éléments de référence et le dernier élément de comptage pour l'autoincrémentation à incrémenter. (Avec use warnings, l'autoincrémentation ne vous avertira jamais que vous utilisez des valeurs indéfinies, car l'autoincrémentation est un moyen accepté pour définir des valeurs indéfinies.) Nous imprimons alors la ligne si nous n'en avons jamais vu avant commençant par ces trois mots, car l'autoincrémentation est une postincrémentation, qui, en plus d'incrémenter la valeur du hachage, renverra l'ancienne valeur vraie s'il y en avait une.

Après la boucle, nous testons %vus à nouveau pour voir si une combinaison particulière de trois mots a été vue. Nous utilisons le fait que nous pouvons mettre un identificateur littéral entre accolades pour qu'il soit automatiquement protégé, comme avec des guillemets. Sinon, nous aurions dû écrire $vus{"nafnaf"} {"nifnif"}{"noufnouf"}, ce qui est une corvée même lorsque vous n'êtes pas poursuivi par un grand méchant loup.

Nous affectons le résultat de $vus{nifnif}{nafnaf}{noufnouf} à une variable temporaire avant même de la tester dans le contexte booléen fourni par le if. Comme l'affectation renvoie sa valeur de gauche, nous pouvons toujours tester la valeur pour voir si elle était vraie. Le my vous fait sauter aux yeux qu'il s'agit d'une nouvelle variable et que nous ne vérifions pas une égalité, mais réalisons une affectation. Cela aurait également parfaitement marché sans le my et un programmeur Perl expert aurait encore remarqué immédiatement que nous utilisions un = au lieu de deux ==. (Un programmeur Perl intermédiaire aurait cependant pu être bluffé. Le programmeur Pascal de n'importe quel niveau aura de l'écume aux lèvres.)

Si l'on passe à l'instruction printf, vous pouvez voir la forme qq() des guillemets que nous avons employée afin de pouvoir interpoler les guillemets ordinaires ainsi que le retour à la ligne. Nous aurions aussi bien pu interpoler directement ici $tmp, puisqu'il s'agit effectivement d'une chaîne entre guillemets, mais nous avons choisi de pousser plus loin l'interpolation via printf. Notre variable temporaire $tmp est maintenant bien pratique, particulièrement depuis que nous ne voulons plus seulement l'interpoler, mais également la tester dans la condition d'un opérateur ?: pour voir si nous devions mettre le mot « coup » au pluriel. Enfin, remarquez que nous avons aligné verticalement les deux champs avec leur marqueur % correspondant dans le format de printf. Si un argument est trop long pour coïncider, vous pouvez toujours aller à la ligne suivante pour l'argument suivant bien que nous n'ayons pas eu à le faire dans ce cas.

Wouah ! Vous en avez assez ? Il existe encore beaucoup d'autres idiomes dont nous aurions pu débattre, mais ce livre est déjà suffisamment lourd. Mais nous aimerions encore parler d'un usage idiomatique de Perl, l'écriture de générateurs de programmes.

Depuis le jour, ou presque, où les gens se sont aperçus pour la première fois qu'ils pouvaient écrire des programmes, ils ont commencé à écrire des programmes qui écrivaient d'autres programmes. Nous les appelons souvent des générateurs de programmes. (Les historiens se souviennent que RPG signifiait Report Program Generator bien avant Role Playing Game.) De nos jours, on l’appellerait probablement des « usines à programmes », mais les gens des des générateurs sont arrivés les premiers, c'est donc leur nom qui a prévalu.

Quiconque a déjà écrit un générateur de programmes sait que cela peut vous donner un strabisme divergent quand bien même vous portez des verres correcteurs. Le problème vient de ce qu'une grande partie des données du programme ressemble à du code, a la couleur du code, mais n'est pas du code (du moins pas encore). Le même fichier texte contient à la fois des choses qui font quelque chose et des choses qui y ressemblent, mais qui ne font rien. Perl comporte de nombreuses fonctionnalités qui facilitent son intégration avec d'autres langages, textuellement parlant.

(Bien sûr, ces fonctionnalités facilitent l'écriture de Perl en Perl, mais c'est le moins auquel on puisse s'attendre dès à présent.)

24-6-a. Générer d'autres langages en Perl ▲

print &q(< <"FIN");
:      #!$bin/perl
:      eval 'exec $bin/perl -S \$0\${1+"\$@"}'
:            if \$lance_sous_un_shell;
:
FIN

print <<"XML";
   <truc>
   <insense>
    bla bla bla @{[ scalar EXPR ]} bla bla bla
    bla bla bla @{[ LISTE ]} bla bla bla
   </insense>
   </truc> 
XML

24-6-b. Générer du Perl dans d'autres langages ▲

% perl 
# line 2000 "Odyssée" 
# le "#" sur la ligne précédente doit être le premier caractère de la ligne 
warn "les portes du compartiment pod"; # or die 
^D
les portes du compartiment pod at Odyssée line 2001.

# line 1996 "Odyssée" 
eval qq { 
#line 2025 "Hal"
    die "portes du compartiment pod"; 
}; 
print "Problèmes avec $@"; 
warn "J'ai peur de ne pouvoir faire cela", 
^D 
Problème avec les portes du compartiment pod at Hal line 2025. 
J'ai peur de ne pouvoir faire cela at Odyssée line 2001.

24-6-c. Filtres de code source ▲

#!/usr/bin/perl 
use MonFiltreDeDecryptage; @*x$]'0uN&k^Zx02jZ^X{.?s!(f;9Q/^A^@~~8H]|,%@^P:q-= 
...

#!/usr/bin/perl 
use Filter::exec "a2p";    # le traducteur awk-vers-perl 
1,30 { print $1 }

Sur la plupart des systèmes d'exploitation, les lignes dans les fichiers sont terminées par un ou deux caractères qui signalent la fin de ligne. Les caractères varient d'un système à l'autre. Unix utilise traditionnellement \012 (c'est-à-dire le caractère octal 12 en ASCII), un type d'entrées/sorties à la DOS utilise \015\012 et les Mac utilisent \015. Perl emploie \n pour représenter un saut de ligne « logique », indépendamment de la plate-forme. Sur MacPerl, \n signifie toujours \015. Sur les Perl à la DOS, \n signifie généralement \012, mais lorsqu'on accède à un fichier en « mode texte », il est traduit vers (ou depuis) \015\012, selon que vous lisez ou que vous écrivez. Unix fait la même chose sur les terminaux en mode canonique. On se réfère généralement à \015\012 en l'appelant CRLF.

Comme DOS fait une distinction entre les fichiers texte et les fichiers binaires, les Perl à la DOS ont des restrictions sur l'utilisation de seek et tell sur un fichier en « mode texte ». Pour obtenir les meilleurs résultats possible, ne faites seek que sur des emplacements obtenus depuis tell. Si toutefois vous utilisez la fonction interne de Perl binmode sur le handle de fichier, vous pouvez généralement faire seek et tell en toute impunité.

Un malentendu fréquent dans la programmation de sockets est que \n vaudra \012 partout. Dans beaucoup de protocoles Internet habituels, \012 et \015 sont spécifiés et les valeurs de \n et \r de Perl ne sont pas fiables puisqu'elles varient d'un système à l'autre :

print SOCKET "Salut, le client !\015\012"; # correct 
print SOCKET "Salut le client !\r\n";      # FAUX

Toutefois, l'utilisation de \015\012 (ou \cM\cJ, ou encore \x0D\x0A, ou même v13.10) peut devenir pénible et disgracieux, et semer la confusion chez ceux qui maintiennent le code. Le module Socket fournit quelques Choses Correctes pour ceux qui en veulent :

use Socket qw(:DEFAULT :crlf); 
print SOCKET "Salut le client !$CRLF" # correct

Lors d'une lecture sur une socket, souvenez-vous que le séparateur d'enregistrement d'entrée par défaut $/ est \n, ce qui signifie que vous avez encore du travail à faire si vous n'êtes pas sûrs que de ce que vous verrez à travers la socket. Un code de socket robuste devrait reconnaître soit \012 ou \015\012 comme étant la fin de ligne :

use Socket qw(:DEFAULT :crlf); 
local ($/) = LF # pas nécessaire si $/ vaut déjà /012 

while (<SOCKET>) {
    s/$CR?$LF/\n/;   # remplace LF ou CRLF par un saut de ligne logique 
}

De même, un code renvoyant des données textuelles — comme un sous-programme qui va chercher une page web — devrait souvent traduire les sauts de ligne. Souvent, une seule ligne de code suffit :

$donnees =~ s/\015?\012/\n/g; 
return $donnees;

Les ordinateurs stockent les entiers et les nombres à virgule flottante dans des ordres différents (gros-boutiste, big-endian ou petit-boutiste, little-endian) et dans des tailles différentes (32 bits et 64 bits étant les tailles les plus courantes de nos jours). Normalement, vous n'aurez pas à y penser. Mais si votre programme envoie des données binaires à travers une connexion réseau ou s'il écrit sur le disque des données destinées à être lues par un ordinateur différent, il se peut que vous deviez prendre des précautions

Des ordres rentrant en conflit peuvent semer une pagaille absolue dans les nombres. Si un hôte petit-boutiste (comme une CPU Intel) stocke 0x12345678 (305 419 896 en décimal), un hôte grand-boutiste (comme une CPU Motorola) le lira comme 0x78563412 (2 018 915 346 en décimal). Pour éviter ce problème dans les connexions réseau (sur une socket), utilisez pack et unpack avec les formats n et N, qui écrivent des nombres entiers courts et longs dans l'ordre gros-boutiste (également appelé ordre « réseau ») quelle que soit la plate-forme.

Vous pouvez explorer le boutisme de votre plate-forme en dépaquetant une structure de données empaquetée en format natif, comme ceci :

print unpack("h*", pack("s2", 1, 2)), "\n"; 
# '10002000' sur par ex. Intel x86 ou Alpha 21064 en mode petit-boutiste 
# '00100020' sur par ex. Motorola 68040

Pour déterminer votre boutisme, vous pourriez utiliser l'une de ces deux instructions :

$est_gros_boutiste = unpack("h*", pack("s", 1)) =~ /01/; 
$est_petit_boutiste = unpack("h*", pack("s", 1)) =~ /^1/;

Même si deux systèmes ont le même boutisme, il peut encore y avoir des problèmes lors du transfert de données entre des plates-formes 32-bits et 64-bits. Il n'existe pas de bonne solution autre que d'éviter de transférer ou de stocker des nombres binaires bruts. Soit vous transférez et vous stockez les nombres en texte plutôt qu'en binaire, soit vous utilisez des modules comme Data::Dumper ou Storable pour le faire à votre place. Vous avez tout intérêt à utiliser des protocoles orientés texte en toutes circonstances — ils sont plus robustes, plus maintenables et encore plus extensibles que les protocoles binaires.

Bien entendu, avec l'avènement de XML et d'Unicode, notre définition d'un protocole orienté texte devient encore plus souple. Par exemple, vous pouvez transférer, entre deux systèmes où Perl 5.6.0 (ou une version ultérieure) est installé, une séquence d'entiers encodés en tant que caractères en utf8 (la version UTF-8 de Perl). Si les deux extrémités tournent sur une architecture avec des entiers 64-bits, vous pouvez échanger des entiers 64-bits. Sinon, vous êtes limités à des entiers 32-bits. Utilisez pack avec un canevas U* pour envoyer et unpack avec un canevas U* pour recevoir.

Les composants des chemins de fichiers sont séparés par / sur Unix, \ sur Windows et : sur Mac. Certains systèmes n'implémentent ni les liens en dur (link), ni les liens symboliques (symlink, readlink, lstat). Certains systèmes attachent une importance à la casse (majuscules/minuscules) des noms de fichiers, d'autres non et d'autres encore n'y font attention que lors de la création de fichiers, mais pas lors de leur lecture.

Il existe des modules qui peuvent vous aider. Les modules standards File::Spec fournissent des fonctions qui Font La Bonne Chose :

use File::Spec::Functions; 
chdir( updir() );  # monter dans le répertoire supérieur 
$fichier = catfile( curdir(), 'temp', 'fichier.txt');

La dernière ligne lit dans ./temp/fichier.txt sur Unix et Windows ou :temp:fichier.txt sur Mac ou [.temp]fichier.txt sur VMS et stocke le contenu du fichier dans $fichier.

Le module File::Basename, un autre module livré avec Perl qui est également indépendant de la plate-forme, éclate un nom de chemin en ses composants : le nom de fichier de base, le chemin complet vers le répertoire et le suffixe du fichier.

Voici quelques astuces pour écrire des programmes Perl manipulant des fichiers qui soient portables :

• N'utilisez pas deux fichiers du même nom avec des casses différentes, comme test.pl et Test.pl, puisque certaines plates-formes ignorent la casse.
• Limitez vos noms de fichiers à la convention 8.3 (noms de huit lettres et extensions de trois lettres) partout où c'est possible. Vous pouvez souvent vous en sortir avec des noms de fichiers plus longs pour autant que vous soyez sûrs qu'ils resteront uniques lorsqu'on les aura poussés à travers un trou dans le mur de taille 8.3. (Hé, cela s'avère plus facile que de pousser un chameau à travers le chas d'une aiguille.)
• Réduire l'emploi de caractères non alphanumériques dans les noms de fichiers. L'utilisation de soulignés est souvent correcte, mais elle gaspille un caractère qui pourrait être mieux employé pour l'unicité sur les systèmes 8.3. (Souvenez-vous que c'est la raison pour laquelle nous ne mettons habituellement pas de souligné dans les noms de modules.)
• De même, lorsque vous utilisez le module AutoSplit, essayez de limiter vos noms de sous-programmes à huit caractères au plus et ne donnez pas le même nom avec une casse différente à deux sous-programmes. Si vous avez besoin de plus de huit caractères, arrangez-vous pour qu'il y ait unicité sur les huit premiers.

• Utilisez toujours < explicitement pour ouvrir un fichier en lecture ; sinon, sur les systèmes qui autorisent la ponctuation dans les noms de fichiers, un fichier préfixé par un caractère > pourrait être effacé et un fichier préfixé par | pourrait engendrer une ouverture de pipe. Car la forme à deux arguments d'open est magique et elle interprétera les caractères comme >, < et |, ce qui peut être la mauvaise chose à faire. (Sauf si c'est la bonne).

   

  Sélectionnez

  open(FICHIER,  $fichier_existant) or die $!;     # MAUVAIS 
  open(FICHIER,   "<$fichier_existant") or die $!;  # mieux 
  open(FICHIER, "<", $fichier_existant) or die $!; # encore mieux

• Ne présupposez pas que les fichiers texte finiront par un saut de ligne. Ils le devraient, mais les gens oublient quelquefois, particulièrement lorsque leur éditeur de texte les y aide.

Les plates-formes reposant sur une interface graphique sont parfois démunies de toute espèce de ligne de commande, ainsi les programmes exigeant une interface en ligne de commande pourraient ne pas fonctionner partout. Vous n'y pouvez pas grand-chose, à part mettre à jour.

Quelques autres astuces :

• Certaines plates-formes ne peuvent pas supprimer ou renommer des fichiers en train d'être utilisés, souvenez-vous donc de fermer avec close les fichiers lorsque vous en avez fini avec eux. Ne faites pas unlink ou rename sur un fichier ouvert. Ne faites pas tie ou open sur un fichier déjà lié avec tie ou déjà ouvert ; faites d'abord untie ou close sur ce fichier.
• N'ouvrez pas le même fichier plusieurs fois simultanément, car certains systèmes posent d'office des verrous sur les fichiers ouverts.
• Ne dépendez pas d'une variable d'environnement spécifique existant dans %ENV et ne présupposez pas que quoi que ce soit dans %ENV soit insensible à la casse ou préserve la casse. Ne présumez pas de la sémantique de l'héritage d'Unix pour les variables d'environnement ; sur certains systèmes, elles peuvent être visibles par tous les processus.
• N'utilisez pas les signaux, ni %SIG.
• Tâchez d'éviter les globs de noms de fichiers. Utilisez opendir, readdir et closedir à la place. (Depuis la version 5.6.0 de Perl, le glob basique de noms de fichiers est bien plus portable qu'il ne l'était, mais certains systèmes peuvent encore se frotter aux « Unixismes » de l'interface par défaut si vous essayez d'être original.)
• Ne présumez pas des valeurs spécifiques pour les numéros d'erreur ou les chaînes stockées dans $!.

Pour maximiser la portabilité, n'essayez pas de lancer de nouveaux processus. Cela signifie que vous devriez éviter system, exec, fork, pipe, ``, qx// ou open avec un |.

Le problème principal ne réside pas dans les opérateurs eux-mêmes : les commandes lançant des processus externes sont généralement implémentées sur la plupart des plates-formes (bien que certaines n'implémentent aucun type de fork). Les problèmes sont davantage susceptibles de se produire lorsque vous invoquez des programmes externes qui ont des noms, des emplacements, des sorties ou des sémantiques pour les arguments qui varient entre les plates-formes.

Un morceau de code Perl particulièrement populaire est l'ouverture d'un pipe vers sendmail pour que votre programme puisse envoyer un mail :

open(MAIL, '|/usr/lib/sendmail -t') or die "fork sendmail impossible: $!";

Ceci ne marchera pas sur les plates-formes sans sendmail. Pour une solution portable, utilisez l'un des modules de CPAN pour envoyer votre mail, comme Mail::Mailer et Mail::Send dans la distribution MailTools ou Mail::Sendmail.

Les fonctions des IPC System V d'Unix (msg*(), sem*(), shm*()) ne sont pas toujours disponibles, même sur certaines plates-formes Unix.

Il est généralement possible d'élaborer un code XS pour qu'il fonctionne avec n'importe quelle plate-forme, mais les bibliothèques et les fichiers d'en-tête pourraient ne pas être disponibles partout. Si les bibliothèques et les fichiers d'en-tête sont portables, alors il y a une chance raisonnable pour que le code XS le soit également.

Un problème de portabilité différent se produit lors de l'écriture de code XS : la disponibilité d'un compilateur C sur la plate-forme de l'utilisateur final. C apporte avec lui ses propres problèmes de portabilité et l'écriture de code XS vous exposera à certains d'entre eux. L'écriture en Perl pur est un moyen facile d'atteindre la portabilité, car le processus de configuration de Perl traverse des supplices extrêmes pour vous cacher les tares de portabilité du C.(189)

En général, les modules standard (ceux qui sont livrés avec Perl) fonctionnent sur toutes les plates-formes. Les exceptions notables sont le module CPAN.pm (qui réalise en fait des connexions vers des programmes externes qui peuvent ne pas être disponibles), les modules spécifiques à une plate-forme (comme ExtUtils::MM_VMS) et les modules DBM.

Il n'existe pas un seul module DBM qui soit disponible sur toutes les plates-formes.

SDBM_File et les autres sont généralement disponibles sur tous les portages Unix et à la DOS, mais pas dans MacPerl, où seuls NBDM_File et DB_File sont disponibles.

La bonne nouvelle est qu'au moins un module DBM devrait être disponible et que AnyDBM_File utilisera n'importe quel module qu'il sera capable de trouver. Avec une telle incertitude, vous ne devriez utiliser que les fonctionnalités communes à toutes les implémentations DBM. Par exemple, limitez vos enregistrements à 1 K octet, pas plus. Voir la documentation du module AnyDBM_File pour plus de détails.

Là où c'est possible, utilisez le standard ISO-8601 (« AAAA-MM-JJ ») pour représenter les dates. Les chaînes comme « 1971-06-21 » peuvent facilement être converties vers une valeur spécifique au système avec un module comme Date::Parse. Une liste de valeurs de date et d'heure (comme celle renvoyée par la fonction interne localtime) peut être convertie vers une représentation spécifique au système en utilisant Time::Local.

La fonction interne time renverra toujours le nombre de secondes depuis le commencement de l'« epoch » (l'origine, voir la fonction time au chapitre 29), mais les systèmes d'exploitation ont des opinions divergentes concernant la date à laquelle cela s'est produit. Sur la plupart des systèmes, l'origine est fixée au 1er janvier 1970 à 00:00:00 UTC, mais elle a commencé 66 ans plus tôt sur Mac et sur VMS elle a démarré le 17 novembre 1858 à 00:00:00. Ainsi, pour obtenir des dates portables, vous voudrez peut-être calculer un décalage pour l'origine :

require Time::Local; 
$decalage = Time::Local::timegm(0, 0, 0, 1, 0, 70);

La valeur de $decalage sur Unix et Windows vaudra toujours, 0 mais sur Macs et VMS, elle pourra valoir un nombre plus grand. Il est alors possible d'ajouter $decalage à une valeur de date et d'heure Unix pour obtenir ce qui devrait être la même valeur sur tous les systèmes.

La représentation par le système de l'heure du jour et de la date calendaire peut être contrôlée par des moyens largement différents. Ne présupposez pas que le fuseau horaire soit stocké dans $ENV{TZ}. Et même s'il l'est, ne présupposez pas que vous pouvez le contrôler via cette variable.

Utilisez de l'Unicode dans vos programmes. Faites toutes les conversions depuis et vers d'autres jeux de caractères dans vos interfaces vers le monde extérieur. Voir le chapitre 15, Unicode.

En dehors du monde d'Unicode, vous devriez présumez de peu en ce qui concerne les jeux de caractères et de rien du tout à propos des valeurs de ord pour les caractères. Ne présupposez pas que les caractères alphabétiques aient des valeurs de ord séquentielles. Les lettres minuscules peuvent venir avant ou après les majuscules ; les majuscules et les minuscules peuvent être mêlées de manière à ce qu'à la fois a et A viennent avant b ; les caractères accentués et les autres caractères internationaux peuvent être mêlés pour que ä vienne avant b.

Si votre programme opère sur un système POSIX (une hypothèse plutôt large), consultez la page de manuel de perllocale pour plus d'informations sur les locales de POSIX. Les locales affectent les jeux de caractères et les encodages ainsi que la date et l'heure, entre autres choses. Une utilisation correcte des locales rendra votre programme un peu plus portable ou au moins, plus pratique et nativement amical pour les utilisateurs non anglo-saxons. Mais soyez conscients que les locales et Unicode ne se mélangent pas encore très bien.

Lorsqu'il est nécessaire d'avoir du code spécifique à la plate-forme, pensez à le garder à un endroit qui facilite le portage vers d'autres plates-formes. Utiliser le module Config et la variable spéciale $^O pour marquer les différences entre les plates-formes.

Faites attention aux tests que vous fournissez avec votre module ou vos programmes. Le code d'un module peut être totalement portable, mais ses tests peuvent ne pas l'être tout à fait. Ceci arrive souvent lorsque les tests engendrent d'autres processus ou appellent des programmes externes pour faciliter les contrôles ou lorsque (comme on l'a remarqué ci-dessus) les tests présument de certaines choses concernant le système de fichiers et les chemins. Prenez garde à ne pas dépendre d'un style d'affichage spécifique pour les erreurs, même en vérifiant $! pour les erreurs « standards » après un appel système. Utilisez plutôt le module Errno.

Souvenez-vous qu'un bon style transcende à la fois le temps et les cultures, ainsi, pour une portabilité maximale, vous devez chercher à comprendre ce qui est universel parmi les exigences de votre existence. Les personnes les plus équilibrées ne sont pas prisonnières et n'ont pas à l'être, car elles ne se soucient pas d'être à la mode eu égard à leur propre culture, de programmation ou autre. La mode est variable, mais le style est constant.

La plupart des formats de document exigent que le document entier soit dans ce format. Pod est plus indulgent : vous pouvez insérer du pod dans tout type de fichier, en vous reposant sur les traducteurs de pod pour l'extraire. Certains fichiers sont entièrement constitués de pod pur à 100 %. Mais d'autres, notamment les programmes Perl et les modules, peuvent contenir une belle quantité de pod dispersée de-ci de-là au bon vouloir de l'auteur. Il suffit à Perl de sauter le texte en pod lorsqu'il analyse le fichier en vue de l'exécuter.

L'analyseur lexical de Perl sait où commencer à sauter le pod lorsqu'à un certain endroit où il trouverait d'ordinaire une instruction, il rencontre à la place une ligne commençant par un signe égal et un identificateur, comme ceci :

=head1 Ici se trouvent les pods !

Ce texte, ainsi que tout ce qui se trouve jusqu'à et y compris une ligne commençant par =cut, sera ignoré. Cela vous permet d'entremêler votre code source et votre documentation en toute liberté, comme dans :

=item guinde

La fonction guinde() se comportera de la façon la plus spectaculairement 
coincée que vous puissiez imaginer, avec aussi peu de naturel qu'une 
pyrotechnie cybernétique.

=cut

sub guinde() {
    my $arg = shift; ... 
}

=item guincher

La fonction guincher() permet la génération autodidact d'épistémologie.
 
=cut

sub guincher {
    print "La génération d'épistémologie n'est pas implémentée sur
           cette plate-forme.\n";
}

Pour d'autres exemples, regardez dans n'importe quel module standard ou venant de CPAN. Ils sont tous supposés venir avec du pod, et pratiquement tous le font, excepté ceux qui ne le font pas.

Puisque le pod est reconnu par l'analyseur lexical de Perl et rejeté, vous pouvez également utiliser une directive pod appropriée pour inhiber rapidement une section de code arbitrairement longue. Utilisez un bloc pod =for pour inhiber un paragraphe ou une paire =begin/=end pour une section plus grosse. Nous détaillerons la syntaxe de ces directives pod plus tard. Souvenez-vous cependant que dans les deux cas, vous êtes toujours dans le mode pod après ceci, vous avez donc besoin de faire un =cut pour revenir au compilateur.

print "reçu 1\n";

=for comment

Ce paragraphe seul est ignoré par tout le monde sauf le mythique traducteur « comment » (N.d.t commentaire). Lorsque c'est fait, vous êtes toujours en mode pod et non en mode programme. 
print "reçu 2\n"; 

=cut 

# OK, à nouveau dans le programme réel 
print "reçu 3\n"; 

=begin commentaire 

print "reçu 4\n"; 
tout ce qui se trouve ici 
sera ignoré 
par tout le monde 
print "reçu 5\n"; 

=end commentaire 

=cut 

print "reçu 6\n";

Ceci affichera qu'on a reçu 1, 3 et 6. Souvenez-vous que ces directives pod ne peuvent pas aller partout. Vous devez les mettre seulement là où l'analyseur s'attend à trouver une nouvelle instruction, pas juste au milieu d'une expression, ni à d'autres endroits arbitraires.

Du point de vue de Perl, tout ce qui est balisé par pod est rejeté, mais du point de vue des traducteurs de pod, c'est le code qui est rejeté. Les traducteurs de pod voient le texte qui reste comme une séquence de paragraphes séparés par des lignes blanches. Tous les traducteurs de pods modernes analysent le pod de la même manière, en utilisant le module standard Pod::Parser. Ils ne se différencient que par leur sortie, puisque chaque traducteur se spécialise dans un format de sortie.

Il existe trois sortes de paragraphes : les paragraphes « tels quels » (verbatim), les paragraphes de commandes et les paragraphes de prose.

26-1-a. Paragraphes « tels quels » ▲

26-1-b. Directives pod ▲

=over 4

=item * 

Armure de mithril 

=item * 

Manteau elfique 

=back

=over 4 

=item 1. 

Premièrement, dites "ami". 

=item 2. 

Deuxièmement, entrez dans la Moria. 

=back

=over 4 

=item armure() 

Description de la fonction armure() 

=item chant() 

Description de la fonction chant()

=for html 
<p> Voici un paragraphe en <small>HTML</small> <flash>brut</flash> </p>

=begin html 

<br>Figure 1.<img src="figure.png"><br> 

=end html 

=begin text 

------------------
|   truc          |
|          machin |
------------------ 
^^^^ Figure 1. ^^^^ 

=end text

26-1-c. Séquences pod ▲

L<texte |nom> 
L<texte |nom/ident> 
L<texte |nom/"sec"> 
L<texte |"sec"> 
L<texte |/"sec">

Z<>=vous voyez ?

Z<>From veut dire "de la part de" en anglais...

C<$a E<lt>=E<gt> $b>

C<< $a <=> $b >>

C<<< $a <=> $b >>> 
C<<<< $a <=> $b >>>>

Perl est livré avec plusieurs traducteurs de pod qui convertissent les documents en pod (ou le pod inclus dans d'autres types de documents) vers divers formats. Tous devraient travailler purement sur 8 bits.

pod2text

• Convertit du pod en texte. Normalement, ce texte sera en ASCII sur 7 bits, mais il sera sur 8 bits s'il a reçu une entrée sur 8 bits, ou spécifiquement de l'ISO-8859-1 (ou de l'Unicode) si vous utilisez des séquences telles que LE<uacute>thien pour Lúthien ou EE<auml>rendil pour Eärendil.
  Si vous avez un fichier contenant du pod, la manière la plus facile (mais peut-être pas la plus jolie) de ne visualiser que le pod formaté serait :

% pod2text Fichier.pm | more

• Mais, encore une fois, le pod est supposé être lisible par un humain sans formatage.

pod2man

• Convertit du pod vers le format des pages de manuel d'Unix, qui convient pour être visualisé via nroff (1) ou pour créer des copies composées via troff (1). Par exemple :

% pod2man Fichier.pm | nroff -man | more

• ou

% pod2man Fichier.pm | troff -man -Tps -t > page_temp.ps % ghostview page_temp.ps

• et pour imprimer :

% lpr -Ppostscript page_temp.ps

pod2html

• Convertit le pod en HTML pour aller avec votre navigateur préféré :

% pod2html Fichier.pm > page_temp.html % lynx page_temp.html % netscape -remote "openURL(file:`pwd`/page_temp.html)"

• Le dernier exemple est une astuce de Netscape qui ne fonctionne que si vous avez déjà un navigateur de lancé quelque part pour dire à cette incarnation de charger la page. Sinon, appelez-le exactement comme vous l'avez fait pour lynx.

pod2latex

• Convertit du pod en LATEX.

Des traducteurs supplémentaires pour d'autres formats sont disponibles sur CPAN. Les traducteurs font preuve de comportements par défaut différents selon le format de

sortie. Par exemple, si votre pod contient un paragraphe en prose disant :

Il s'agit ici d'une $variable

alors pod2html changera ça en :

Il s'agit ici d'une <STRONG>$variable</STRONG>

alors que pod2text le laissera sans décoration, puisque le dollar devrait suffire pour que cela soit lisible.

Vous devriez écrire votre pod en restant le plus proche possible du texte « à plat », en vous passant le plus possible de balises explicites. C'est à chaque traducteur de décider comment créer des signes de protection appariés, comment remplir et ajuster le texte, comment trouver une fonte plus petite pour les mots entièrement en majuscules, etc. Puisqu'ils ont été écrits pour traiter la documentation en Perl, la plupart des traducteurs(190) devraient également reconnaître des éléments sans décoration comme ceux-ci et les présenter de manière appropriée :

• HANDLE_FICHIER
• $scalaire
• tableau
• fonction()
• page_man(3r)
• quelquun@quelquepart.com
• http://truc.com/

Perl apporte également plusieurs modules standard pour analyser et convertir du pod, comprenant Pod::Checker (et l'utilitaire associé podchecker) pour vérifier la syntaxe des documents pod, Pod::Find pour trouver des documents pod dans les arborescences de répertoires et Pod::Parser pour créer vos propres utilitaires pod.

Remarquez que les traducteurs de pod devraient seulement regarder les paragraphes commençant par une directive pod (cela facilite l'analyse), puisqu'en fait le compilateur sait rechercher les séquences d'échappement pod même au milieu d'un paragraphe. Cela signifie que le secret suivant sera ignoré à la fois par le compilateur et par les traducteurs.

$a=3; 
=secret 
warn "Ni du POD, ni du CODE !?" 
=cut back 
print "reçu $a\n";

Vous ne devriez probablement pas vous reposer sur le fait que le warn restera à jamais sorti du pod. Les traducteurs de pod ne sont pas tous sages à cet égard et le compilateur pourrait devenir moins sélectif un jour ou l'autre.

Pod a été conçu tout d'abord et surtout pour être facile à écrire. Un corollaire de la simplicité de pod est qu'elle permet d'écrire soi-même des outils simples pour traiter du pod. Si vous recherchez des directives pod, vous n'avez qu'à positionner le séparateur d'enregistrements en entrée en mode paragraphe (peut-être avec l'option -00) et n'accorder de l'attention qu'à ce qui ressemble à du pod.

Voici par exemple un simple programme afficheur de plan en pod :

#!/usr/bin/perl -l00n 
# planpod -affiche le plan en pod 
next unless /^=head/; 
s/^=head(\d)\s+/ " x ($1 * 4 -4)/e; 
print $_, "\n";

Si vous le lancez sur le présent chapitre de ce livre, vous obtiendrez quelque chose comme cela :

Plain Old Documentation

    Pod en quelques mots
        Paragraphes « tels quels »
        Directives pod
        Séquences pod
    Traducteurs et modules pod
    Écrire vos propres outils pod
    Pièges du pod
    Documenter vos programmes perl

Cet afficheur de plan en pod n'a pas vraiment fait attention au fait que le bloc pod était valide ou non. Puisque ce qui est en pod et ce qui ne l'est pas peuvent s'entremêler dans le même fichier, cela n'a pas toujours de sens de lancer des outils génériques pour rechercher et analyser le fichier complet. Mais ce n'est pas un problème, étant donné qu'il est si facile d'écrire des outils pour le pod. Voici un outil qui est attentif aux différences entre le pod et ce qui n'est pas du pod, puis n'affiche que le pod :

#!/usr/bin/perl -00 
# catpod -n'affiche que ce qui est en pod 
while (<>) {
    if (!$enpod) { $enpod = /^=/;           }
    if ($enpod)  { $enpod = !/=cut/; print; } 
} continue {
    if (eof)     { close ARGV; $enpod = ''; } 
}

Vous pourriez utiliser ce programme sur un autre programme ou un module en Perl, puis mettre un pipe sur la sortie vers un autre outil. Par exemple, si vous possédez le programme wc(1)(191) pour compter le nombre de lignes, de mots et de caractères, vous pourriez l'approvisionner avec la sortie de catpod pour qu'il ne considère dans son comptage que le pod :

% catpod MonModule.pm | wc

Il existe beaucoup d'endroits où le pod vous permet d'écrire des outils rudimentaires de façon simplissime en utilisant directement du Perl brut. Maintenant que vous avez catpod à utiliser comme composant, voici un autre outil pour ne montrer que le code indenté :

#!/usr/bin/perl -n00 
# podlit -affiche les blocs littéraux indentés 
# à partir de pod en entrée 
print if /^\s/;

Que pourriez-vous faire avec ça ? Eh bien, vous pourriez premièrement vouloir vérifier le code dans le document avec perl -wc. Ou peut-être voudriez-vous une fonctionnalité de grep(1)(192) qui ne regarde que les exemples de code :

% catpod MonModule.pm | podlit | grep nom_fonc

Cette philosophie, selon laquelle les outils et les filtres sont des parties interchangeables (et testables unitairement), est une approche tout bonnement simple et puissante pour concevoir des composants logiciels réutilisables. C'est une forme de paresse de ne construire qu'une solution minimale pour accomplir le travail aujourd'hui — du moins, pour certains types de travaux.

Cependant, pour d'autres tâches, ceci peut même s'avérer contre-productif. Parfois, il y a plus de travail à écrire un outil à partir de rien et parfois moins. Pour ceux que nous vous avons montrés précédemment, les prouesses naturelles de Perl en ce qui concerne le traitement du texte sont tout indiquées pour appliquer « la force brute ». Mais tout ne fonctionne pas de cette façon. En jouant avec le pod, vous pourriez remarquer que bien que ses directives soient simples à analyser, ces séquences peuvent s'avérer plus risquées. Bien que des traducteurs, hum, pas très corrects, ne s'adaptent pas à ceci, les séquences peuvent s'imbriquer dans d'autres séquences et peuvent avoir des délimiteurs de taille variable.

Au lieu de vous mettre à coder vous-même ce code d'analyse, les paresseux chercheront une autre solution. Le module standard Pod::Parser remplit ce contrat. Il est tout particulièrement utile pour les tâches difficiles, comme celles qui nécessitent une réelle analyse des morceaux internes des paragraphes, une conversion vers d'autres formats de sortie, et ainsi de suite. Il est plus facile d'utiliser le module pour les cas compliqués, car la quantité de code à laquelle vous aboutirez est plus petite. C'est également mieux, car l'analyse épineuse est déjà réalisée pour vous. Il s'agit tout à fait du même principe que l'emploi de catpod dans une chaîne de pipes.

Le module Pod::Parser adopte une approche intéressante dans son travail. C'est un module orienté objet d'une facture différente de la plupart de ceux que vous avez vus dans ce livre. Son objectif premier n'est pas tant de fournir des objets à manipuler directement que d'apporter une classe de base à partir de laquelle d'autres classes peuvent être construites.

Vous créez votre propre classe et héritez de Pod::Parser. Puis vous déclarez des sous-programmes servant de méthodes de rappel (callbacks) que l'analyseur de votre classe parente invoquera. Il s'agit d'une façon de programmer différente des programmes procéduraux donnés précédemment. Dans un sens, il s'agit plus d'un style de programmation déclaratif, car, pour accomplir le travail, vous enregistrez simplement des fonctions et laissez d'autres entités les invoquer pour vous. La logique ennuyeuse du programme est gérée ailleurs. Vous ne faites que donner des morceaux « plug-and-play ».

Voici une réécriture du programme original catpod donné auparavant, mais, cette fois-ci,

elle utilise le module Pod::Parser pour créer votre propre sous-classe :

#!/usr/bin/perl 
# catpod2, classe et programme

package catpod_analyseur; 
use Pod::Parser; 
@ISA = qw(Pod::Parser); 
sub command {
    my ($analyseur, $commande, $paragraphe, $num_ligne) = @_;
    my $hf_sortie = $analyseur->output_handle();
    $paragraphe .= "\n" unless substr($paragraphe, -1) eq "\n";
    $paragraphe .= "\n" unless substr($paragraphe, -2) eq "\n\n";
    print $hf_sortie "=$commande $paragraphe"; 
}

sub verbatim {
    my ($analyseur, $paragraphe, $num_ligne) = @_;
    my $hf_sortie = $analyseur->output_handle();
    print $hf_sortie $paragraphe; 
}

sub textblock {
    my ($analyseur, $paragraphe, $num_ligne) = @_;
    my $hf_sortie = $analyseur->output_handle();
    print $hf_sortie $paragraphe; 
}

sub interior_sequence {
    my ($analyseur, $commande_seq, $argument_seq) = @_;
    return "$commande_seq<$argument_seq>"; 
}

if (!caller) {
    package main;
    my $analyseur = catpod_analyseur->new();
    unshift @ARGV, '-' unless @ARGV;
    for (@ARGV) { $analyseur->parse_from_file($_); } 
} 
1; 
__END__

=head1 NAME 

documentation décrivant le nouveau programme catpod, ici

Comme vous le voyez, c'est un peu plus long et plus compliqué. C'est également plus évolutif, car tout ce que vous avez à faire est de brancher vos propres méthodes lorsque vous voulez que votre sous-classe agisse différemment que sa classe de base.

Le dernier morceau à la fin, où il est écrit !caller, vérifie si le fichier est utilisé en tant que module ou en tant que programme. S'il est employé comme programme, il n'y aura alors pas d'appelant (caller en anglais). Il lancera donc son propre analyseur (en utilisant la méthode new dont il a hérité) sur les arguments de la ligne de commande. Si aucun nom de fichier n'a été passé, il prend l'entrée standard, tout comme le faisait la version précédente.

À la suite du code du module, il y a un marqueur __END__, une ligne vide sans espace, puis la propre documentation en pod du programme/module. Il s'agit d'un exemple d'un fichier qui est à la fois un programme et un module et sa propre documentation. Il est probablement plusieurs autres choses également.

Pod est assez direct à apprendre et à écrire, mais il est toujours possible de rater quelques petites choses :

• Il est vraiment facile d'oublier le signe supérieur final.
• Il est vraiment facile d'oublier la directive =back finale.
• Il est facile de mettre accidentellement une ligne vide au milieu d'une longue directive =for comment. Songez à utiliser =begin/=end à la place.
• Si vous faites une faute de frappe sur l'une des deux balises d'une paire =begin/=end, cela avalera tout le reste de votre fichier (en ce qui concerne le pod). Songez à utiliser =for à la place.
• Les traducteurs de pod exigent que les paragraphes soient séparés par des lignes complètement vides ; c'est-à-dire, par au moins deux caractères de saut de ligne consécutifs (\n). Si vous avez une ligne avec des espaces ou des tabulations, elle ne sera pas prise comme une ligne blanche. Ceci peut causer le traitement de deux paragraphes ou plus comme s'il n'y en avait qu'un seul.
• La signification d'un « lien » n'est pas définie par pod et c'est à chaque traducteur de décider quoi en faire. (Si vous commencez à penser que la plupart des décisions ont été reportées sur les traducteurs et pas dans pod, vous avez raison.) Les traducteurs ajouteront souvent des mots autour d'un lien L<>, ainsi, « L<truc(1)> » deviendra « la page de manuel truc(1) », par exemple. Vous ne devriez donc pas écrire des choses comme « la page de manuel L<truc> » si vous voulez que le document traduit soit raisonnablement lisible : cela aboutirait à « la page de manuel la page de manuel truc(1) ».

Si vous avez besoin d'un contrôle total sur le texte utilisé dans un lien, utilisez plutôt la forme L<montre ce texte|truc>.

Le programme standard podchecker vérifie la syntaxe pod pour trouver les erreurs et les avertissements. Par exemple, il recherche les séquences pod inconnues et les lignes blanches trompeuses contenant des espaces. Il est toujours recommandé de passer votre document à travers différents traducteurs de pod et de corriger les résultats. Certains des problèmes que vous trouverez peuvent être des idiosyncrasies des traducteurs particuliers, ce sur quoi vous voudrez ou non travailler.

Et, comme toujours, tout est sujet à modification selon les caprices d'un hacker quelconque.

Nous espérons que vous documentez votre code, que vous soyez ou non un hacker quelconque. Si c'est le cas, vous pouvez souhaiter inclure les sections suivantes dans votre pod :

=head1 NOM

    Le nom de votre programme ou de votre module. 

=head1 SYNOPSIS 

    Une description d'une ligne sur ce que fait (soi-disant) votre programme ou votre module. 

=head1 DESCRIPTION 

    La masse de votre documentation. (Masse est le terme approprié dans ce contexte.) 

=head1 AUTEUR 

    Qui vous êtes. (Ou un pseudonyme, si vous avez honte de votre programme.) 

=head1 BOGUES 

    Ce que vous avez mal fait (et pourquoi ce n'était pas vraiment votre faute). 

=head1 VOIR AUSSI 

    Où les gens peuvent trouver des informations en rapport (pour qu'ils puissent travailler sur vos bogues). 

=head1 COPYRIGHT 

    Les instructions légales. Si vous voulez revendiquer un copyright
    explicite, vous devriez dire quelque chose comme : 
Copyright 2013, Randy Waterhouse. Tous droits réservés?
    Beaucoup de modules ajoutent également :
    Ce programme est un logiciel libre. Vous pouvez le copier ou le redistribuer sous les mêmes termes que Perl lui-même.

Un avertissement : si vous êtes sur le point de mettre votre pod à la fin du fichier et que vous utilisez les tokens __END__ ou __DATA__, assurez-vous de mettre une ligne vide avant la première directive pod :

__END__ 

=head1 NOM 

Moderne -Je suis vraiment un modèle d'un module essentiel moderne

Sans la ligne vide avant le =head1, les traducteurs de pod ignoreront le début de votre documentation (vaste, précise, cultivée).

Pour comprendre pourquoi Perl est ainsi défini (ou indéfini), il faut d'abord comprendre la raison même pour laquelle Perl existe. Sortons donc le grimoire poussiéreux...

En 1986, Larry était un programmeur système sur un projet de réseaux à grande échelle et à multiples niveaux de sécurité. Il s'occupait d'une installation composée de trois Vax et de trois Sun sur la Côte Ouest, connectés par une ligne série chiffrée à 1200 bauds à une configuration similaire sur la Côte Est. Comme son travail consistait surtout en du support (il n'était pas programmeur sur le projet, seulement le gourou système), il put exploiter ses trois vertus (paresse, impatience et orgueil) pour développer et améliorer toutes sortes d'outils intéressants — comme rn, patch et warp.(193)

Un jour, alors que Larry finissait de découper rn en petits morceaux, le laissant éparpillé sur le sol de son répertoire, le Grand Patron vint à lui et dit : « Larry, il nous faut un système de gestion de configurations et de contrôle pour les six Vax et les six Sun. Dans un mois. Exécution ! »

Larry, qui n'a jamais été un fainéant, se demanda quel était le meilleur moyen d'obtenir un système de gestion de configurations transcontinental, sans devoir partir de zéro, qui permettrait de visualiser les rapports d'incidents sur les deux côtes, avec validation et contrôle. La réponse tenait en un mot : B-news.(194)

Larry commença par installer les news sur ces machines et ajouta deux commandes de contrôle : une commande « append » pour enrichir un article existant et une commande « synchronize » pour que les numéros d'articles restent les mêmes sur les deux côtes. La gestion du contrôle passerait par RCS (Revision Control System) et les validations et les soumissions se feraient par les news et rn. Jusqu'ici, tout allait bien.

Puis, le Grand Patron lui demanda de fournir des rapports. Les news étaient maintenues dans des fichiers séparés sur une machine maître, avec un grand nombre de références croisées entre les fichiers. La première pensée de Larry fut : « Utilisons awk. » Malheureusement, le awk d'alors ne savait pas gérer l'ouverture et la fermeture de plusieurs fichiers en fonction des informations de ces fichiers. Larry ne voulait pas programmer un outil spécifique. C'est ainsi qu'un nouveau langage naquit.

À l'origine, il ne s'appelait pas Perl. Larry envisagea un certain nombre de noms avec ses collègues et son entourage (Dan Faigin, qui écrivit cette histoire et Mark Biggar, son beau-frère, qui l'assista énormément lors de la conception initiale). Larry considéra et rejeta en fait tous les mots de 3 ou 4 lettres du dictionnaire. L'un des premiers avait été « Gloria », inspiré de sa chère et tendre (et épouse). Il se dit rapidement que cela provoquerait trop de confusions d'ordre domestique.

Le nom devint alors « Pearl », qui muta en notre « Perl » actuel, en partie parce que Larry trouva une référence à un autre langage nommé « PEARL », mais surtout parce qu'il est trop paresseux pour taper cinq lettres d'affilée à chaque fois. Évidemment, afin que Perl puisse être utilisé comme l'un de ces mots de quatre lettres chers aux anglophones. (Notez cependant les vestiges du nom initial dans le développement de l'acronyme : « Practical Extraction And Report Language »).

Le Perl des origines avait beaucoup moins de fonctionnalités que celui d'aujourd'hui. La recherche de correspondances et les handles de fichiers étaient là, les scalaires aussi, de même que les formats, mais il ne comportait que très peu de fonctions, pas de tableaux associatifs et juste une implémentation restreinte des expressions régulières, empruntée à rn. Le manuel ne contenait que 15 pages. Mais Perl était plus rapide que sed et awk et commença à être utilisé pour d'autres applications du projet.

Mais Larry était demandé par ailleurs. Un autre Grand Patron arriva un jour et dit : « Larry, il faut assister la R&D » . Et Larry fut d'accord. Il prit Perl avec lui et découvrit qu'il se transformait en un bon outil d'administration système. Il emprunta à Henry Spencer son superbe paquetage d'expressions régulières et le charcuta en quelque chose auquel Henry préférerait ne pas penser à table. Puis Larry ajouta la plupart des fonctionnalités qui lui semblaient bonnes et quelques autres que d'autres personnes désiraient. Il le diffusa sur le réseau.(195) Le reste, comme on dit, appartient à l'histoire.(196)

L'histoire s'est déroulée comme ceci : Perl 1.0 sort le 18 décembre 1987 ; certains prennent toujours au sérieux l'anniversaire de Perl. Perl 2.0 suit en juin 1988 et Randal Schwartz crée la signature légendaire « Just Another Perl Hacker » (juste un autre bidouilleur Perl). En 1989, Tom Christiansen présente le premier tutoriel public au Usenix de Baltimore. Avec Perl 3.0 en octobre 1989, le langage sort et distribué pour la première fois dans les termes de la Licence Publique Générale de GNU.

En mars 1990, Larry écrit le premier poème en Perl (voir la section suivante). Puis lui et Randal écrivent la première édition de ce livre, le « Pink Camel » (le chameau rose ou fushia) ; il est publié en début d'année 1991. Perl 4.0 sort en même temps ; il comprend la Licence Artistique ainsi que la LPG.

L'inauguration du très attendu Perl 5 se déroule en octobre 1994. C'est une réécriture complète de Perl, comprenant des objets et des modules. L'avènement de Perl 5 fait même la couverture du journal The Economist. En 1995, CPAN est officiellement présenté à la communauté Perl. Jon Orwant commence à publier The Perl Journal en 1996. Après une longue gestation, la seconde édition de ce livre, le « Blue Camel » (le chameau bleu) paraît cet automne. La première conférence Perl d'O'Reilly (TPC) se déroule à San José, en Californie, durant l'été 1997. Des événements marquants arrivent maintenant presque quotidiennement, donc, pour la suite de l'histoire, regardez la Perl Timeline sur CPAST, le Comprehensive Perl Arcana Society Tapestry (N.d.T. La ligne du temps sur la tapisserie de la société des arcanes détaillés de Perl) sur history.perl.org.

La contrefaçon ci-contre apparut sur Usenet le 1er avril 1990. Elle est présentée sans commentaires, essentiellement afin de montrer quel degré d'abjection peuvent atteindre les métaphores d'un langage de programmation typique. Larry est particulièrement soulagé que « Black Perl », écrit à l'origine pour Perl 3, ne compile plus sous Perl 5.

Le, euh, corpus de Larry a été heureusement supplanté par la Poétesse Perl régnante, Sharon Hopkins. Elle a écrit un certain nombre de poèmes Perl, ainsi qu'un article sur la poésie en Perl, qu'elle a présenté à la Conférence Technique Usenix de l'hiver 1992, intitulé « Camel and Needles: Computer Poetry Meets the Perl Programming Language » (Le chameau et les aiguilles : quand la poésie informatique rencontre le langage de programmation Perl). (L'article est disponible sous misc/poetry.ps sur CPAN.) Non contente d'être la plus prolifique des poètesses Perl, Sharon est également la plus largement publiée, le poème suivant étant sorti dans l'Economist et le Guardian :

#!/usr/bin/perl

APPEAL: 

listen (please, please); 

open yourself, wide;
    join (you, me), 
connect (us,together), 

tell me. 

do something if distressed;

    @dawn, dance;
    @evening, sing;
    read (books,$poems,stories) until peaceful;
    study if able;

    write me if-you-please; 

sort your feelings, reset goals, seek (friends, family, anyone);
        do*not*die (like this)
        if sin abounds; 

keys (hidden), open (locks, doors), tell secrets; 
do not, I-beg-you, close them, yet.

                        accept (yourself, changes),
                        bind (grief, despair); 

require truth, goodness if-you-will, each moment; 

select (always), length(of-days) 

# listen (a perl poem) 
# Sharon Hopkins 
# rev. June 19, 1995