Bases perldata, perlvar, perlsyn, perlop, perlsub
Exécution perlrun, perldebug
Fonctions perlfunc
Objets perlref, perlmod, perlobj, perltie
Structure de données perlref, perllol, perldsc
Modules perlmod, perlmodlib, perlsub
Regexp perlre, perlfunc, perlop, perllocale
Évoluer vers perl5 perltrap, perl
Lier au langage C perlxstut, perlxs, perlcall, perlguts, perlembed
Divers http://www.perl.com/CPAN/doc/FMTEYEWTK/index.html
(ce n'est pas une page man, mais très utile)
Un sommaire rudimentaire des pages de manuel de Perl existantes se trouve dans perltoc.
perl -de 42
Maintenant, tapez plutôt un code Perl valide, et il sera immédiatement évalué (éxécuté). Vous pouvez également examiner la table des symboles, voir l'évolution de la pile, vérifier les valeurs des variables, fixer des points d'arrêt, et faire d'autres opérations typiquement disponibles dans les debuggers symboliques.
Avez-vous utilisé "use strict" ? Cela vous empêche d'utiliser des références symboliques, vous oblige à prédéclarer les sous-programmes que vous appelez comme simple mot, et (probablement le plus important) vous oblige à déclarer vos variables avec "my", "our" ou "use vars".
Avez-vous vérifié les résultats de chacune des commandes système ? Le système d'exploitation (et ainsi Perl) vous indique si elles ont fonctionné ou pas, et la raison de l'échec éventuel.
open(FH, "> /etc/cantwrite")
or die "Couldn't write to /etc/cantwrite: $!\n";
Avez-vous lu perltrap ? C'est plein de trucs et astuces pour les programmeurs Perl débutants ou initiés. Il y a même des sections pour ceux d'entre vous habitués aux langages awk et C.
Avez-vous essayé le debugger Perl, décrit dans perldebug ? Vous pouvez exécuter votre programme et voir ce qu'il fait, pas à pas et ainsi comprendre pourquoi ce qu'il fait n'est pas conforme à ce qu'il devrait faire.
Voici un exemple d'utilisation de Benchmark :
use Benchmark;
@junk = `cat /etc/motd`; $count = 10_000;
timethese($count, {
'map' => sub { my @a = @junk;
map { s/a/b/ } @a;
return @a
},
'for' => sub { my @a = @junk;
local $_;
for (@a) { s/a/b/ };
return @a },
});
Voici l'affichage généré (sur une machine particulière---vos résultats dépendront de votre matériel, du système d'exploitation, et de la charge de travail de votre machine) :
Benchmark: timing 10000 iterations of for, map...
for: 4 secs ( 3.97 usr 0.01 sys = 3.98 cpu)
map: 6 secs ( 4.97 usr 0.00 sys = 4.97 cpu)
Soyez conscient qu'un bon benchmark est très difficile à écrire. Il ne teste que les données que vous lui passez, et ne prouve vraiment que peu de choses sur les diverses complexités d'algorithmes variés.
perl -MO=Xref[,OPTIONS] scriptname.plx
Bien sûr, si vous suivez bien les recommandations de perlstyle, vous ne devriez pas avoir besoin de reformater. L'habitude de formater votre code au fur et à mesure que vous l'écrivez vous évitera bien des erreurs. Votre éditeur devrait vous aider pour ceci. Le mode perl d'emacs peut vous être d'une grande aide pour quasiment tout le code, et même d'autres éditeurs moins programmables peuvent vous fournir une assistance significative. Tom ne jure que par les réglages suivants sous vi et ses clones :
set ai sw=4
map! ^O {^M}^[O^T
Placez maintenant cela dans votre fichier .exrc (en remplaçant les accents circonflexes par des caractères de contrôle) et c'est bon. En mode insertion, ^T est pour l'indentation, ^D pour la suppression de l'indentation, et ^O pour l'indentation d'un bloc --- as it were [NDT ?]. Si vous n'avez pas utilisé le dernier, vous manquez quelque chose. Un exemple plus complet, avec des commentaires, peut être trouvé en http://www.perl.com/CPAN-local/authors/id/TOMC/scripts/toms.exrc.gz
Si vous avez l'habitude d'utiliser le programme vgrind pour imprimer un beau code sur imprimante laser, vous pouvez vous servir de http://www.perl.com/CPAN/doc/misc/tips/working.vgrind.entry, mais le résultat n'est pas vraiement satisfaisant pour du code sophistiqué.
Le programme a2ps sur http://www.infres.enst.fr/%7Edemaille/a2ps/ fait beaucoup pour imprimer des sorties de documents joliment imprimées.
Pour faire court, vous devez juste apprendre la boîte à outils. Toutefois, si vous n'êtes pas sous Unix, alors votre vendeur ne s'est probablement pas soucié de vous fournir une boîte à outils correcte sur le système soi-disant complet pour lequel vous avez dépensé votre argent durement gagné.
PerlBuilder (l'URL viendra plus tard) est un environnement de développement intégré pour Windows qui supporte le développement Perl. Les programmes Perl sont toutefois juste du texte simple, vous pouvez donc télécharger emacs pour Windows (???) ou un clone de vi (vim) fonctionnant sous win32 (http://www.cs.vu.nl/%7Etmgil/vi.html). Si vous transférez des fichiers Windows sous Unix, prenez soin de le faire en mode ASCII pour que les fins de lignes soient modifiées de façon appropriée.
Dans le répertoire du code source de Perl, vous trouverez un répertoire nommé ``emacs'', qui contient un mode d'édition perl qui colore les instructions Perl, fournit une aide contextuelle, et autres choses sympathiques.
Notez que le mode perl de Emacs changera les lignes du genre "main'foo" (apostrophe), et modifiera les tabulations et surlignages. Vous utilisez probablement de toute façon "main::foo" dans votre nouveau code Perl, donc ceci n'est pas bien grave.
D'inestimables aides pour la programmation en Perl/Tk : la FAq Perl/Tk à http://w4.lns.cornell.edu/%7Epvhp/ptk/ptkTOC.html , le guide de référence Perl/Tk à http://www.perl.com/CPAN-local/authors/Stephen_O_Lidie/ et les pages man à http://www-users.cs.umn.edu/%7Eamundson/perl/perltk/toc.html .
Une approche différente est d'utiliser Autoload pour le code peu utilisé. Voyez les modules AutoSplit et AutoLoader dans la distribution standard pour ce faire. Vous pouvez aussi localiser le goulot d'étranglement et penser à écrire cette partie en C, de la même façon que nous avons l'habitude d'écrire les parties lentes de C en assembleur. Au lieu de réécrire en C, vous pouvez aussi utiliser des modules ayant leurs sections critiques déjà écrites en C (par exemple, le module PDL du CPAN).
Dans certains cas, il peut être valable d'utiliser le compilateur final pour produire du code binaire (pour gagner le temps de compilation du code) ou de compiler en C, ce qui évitera à coup sûr le temps de compilation, et gagnera parfois un peu de temps à l'exécution. Voyez la question portant sur la compilation des programmes Perl, pour en savoir plus sur le compilateur final---les avantages ne sont pas si évidents que vous le souhaiteriez.
Si vous liez votre exécutable perl à une librairie partagée libc.so, vous pouvez souvent gagner 10-25 % en performance en le liant plutôt avec une librairie statique libc.a à la place. Cela fera un exécutable plus important, mais vos programmes (et programmeurs) Perl vous en remercieront. Voyez le fichier INSTALL dans le code source de la distribution pour plus d'informations.
Des rapports sans fondements prétendent que les interpréteurs Perl utilisant sfio dépassent de beaucoup en performance ceux qui ne les utilisent pas (pour des applications avec des I/O intensives). Pour essayer ceci, voyez le fichier INSTALL dans le source de la distribution, et plus spécialement la section ``Selecting File I/O mechanisms''.
Le programme undump était un vieil essai pour améliorer la vitesse de vos programmes Perl en sauvegardant les objets déjà compilés sur le disque dur. Ce n'est plus une option viable, puisque cela ne fonctionnait que sur peu d'architectures, et que ce n'était pas une bonne solution de toute façon.
Dans certains cas, l'usage de substr() ou vec() pour simuler des tableaux peut être très bénéfique. Par exemple, un tableau de milliers de booléens prendra au moins 20 000 octets, mais il peut être remplacé par un vecteur de 125 octets ce qui économise considérablement la mémoire. Le module standard Tie::SubstrHash peut aussi aider pour certains types de structures de données. Si vous travaillez avec des structures de données spécifiques (matrices, par exemple), les modules qui les implémentent en C peuvent utiliser moins de mémoire que leurs équivalents en Perl.
Autre chose, essayez de savoir si Perl a été compilé avec le malloc système ou le malloc de Perl. Quel qu'il soit, essayez d'utiliser l'autre, et voyez si cela fait une différence. Les informations sur malloc se trouvent dans le fichier INSTALL du source de la distribution. Vous pouvez savoir quel malloc vous utilisez en tapant "perl -V:usemymalloc".
sub makeone {
my @a = ( 1 .. 10 );
return \@a;
}
for $i ( 1 .. 10 ) {
push @many, makeone();
}
print $many[4][5], "\n";
print "@many\n";
On nous a rapporté que sous Linux (Redhat 5.1) sur Intel, "undef $scalar" rend la mémoire au système, tandis que ce n'est pas le cas sous Solaris 2.6. En général, essayez-le vous-même pour voir.
De toute manière, une utilisation judicieuse de my() pour vos variables vous assurera que ces variables sont détruites et que Perl peut utiliser leur espace mémoire et l'utiliser dans d'autres parties de votre programme. Une variable globale, bien sûr, n'est jamais détruite, donc vous ne pouvez récupérer leur espace mémoire automatiquement, bien que undef() et/ou delete() provoque le même effet de libérer l'espace mémoire. En général, vous n'avez pas à vous préoccuper de l'allocation et de la désallocation de mémoire avec Perl, mais la capacité de le faire est en cours de développement (préallocation de types de données).
Il y a 2 façons classiques pour éviter cette surcharge. Une solution consiste à exécuter le serveur HTTP Apache (disponible à http://www.apache.org/) avec le module mod_perl ou mod_fastcgi.
Avec mod_perl et le module Apache::Registry (distribué avec mod_perl), httpd fonctionne avec un interpréteur Perl inclus qui précompile votre script puis l'exécute dans le même espace mémoire sans fork. L'extension Apache donne aussi à Perl l'accès à la librairie API du serveur, ce qui fait qu'un module écrit en Perl peut faire quasiment tout ce qu'un module en C peut. Pour en savoir plus sur mod_perl, voyez http://perl.apache.org/
Avec le module FCGI (du CPAN) et le module mod_fastcgi (disponible sur http://www.fastcgi.com/) chacun de vos programmes devient un processus CGI démon permanent.
Chacune de ces 2 solutions peut avoir de grandes conséquences sur votre système et sur votre façon d'écrire vos programmes CGI, donc utilisez-les avec précaution.
Voir http://www.perl.com/CPAN/modules/by-category/15_World_Wide_Web_HTML_HTTP_CGI/
Un produit commercial non gratuit, ``The Velocity Engine for Perl'', (http://www.binevolve.com/ ou http://www.binevolve.com/bine/velocigen) vaut également le coup d'oeil. Cela vous permet d'améliorer les performances de vos programmes Perl, jusqu'à 25 fois plus rapide qu'un Perl CGI normal en fonctionnant en mode Perl persistant, ou 4 à 5 fois plus rapide sans aucune modification à votre programme CGI existant. Des copies d'évaluation avec toutes fonctionnalités sont disponibles sur le site.
Tout d'abord, en aucun cas, vous ne pouvez ôter la permission en lecture, car le code source doit pouvoir être lu pour pouvoir être compilé et interprété. (Ce qui ne signifie pas que le code source d'un script CGI soit accessible en lecture pour les visiteurs du site web, bien qu'il le soit pour ceux qui ont un accès au système de fichiers). Donc vous devez laisser ces permissions au niveau socialement sympathique de 0755.
Certains voient cela comme un problème de sécurité. Si votre programme fait des actions mettant en cause la sécurité du système, et reposent sur la confiance aveugle que vous avez que les visiteurs ne savent pas comment exploiter ces trous de sécurités, alors, votre programme n'est pas sécurisé. C'est parfois possible pour certains de déterminer les choses et les exploiter sans voir le code source. La sécurité qui consiste à être obscure ou à changer des noms pour cacher des bugs au lieu de les résoudre est une sécurité plutôt maigre.
Vous pouvez essayer d'utiliser du cryptage via des filtres de code source (Filter::* au CPAN), mais n'importe quel programmeur sérieux pourra les décrypter. Vous pouvez essayer d'utiliser le compilateur et interpréteur en binaire décrit ci-dessous, mais les plus curieux pourront encore le décompiler. Vous pouvez essayer le compilateur natif de code décrit ci-dessous, mais des crackers peuvent de désassembler. Cela pose différents degrés de difficultés aux personnes qui en veulent à votre code, mais ça ne les empêchera pas de le retrouver (c'est vrai pour n'importe quel langage, pas juste Perl).
Si cela vous ennuie que des personnes puissent profiter de votre code, alors la première chose à faire est d'indiquer une licence restrictive au début de votre code, ce qui vous donne une sécurité légale. Mettez une licence à votre programme et saupoudrez-le de menaces diverses telle que ``Ceci est un programme privé non distribué, de la société XYZ. Votre accès à ce code source ne vous donne pas le droit de l'utiliser bla bla bla.'' Nous ne sommes pas des juristes, bien sûr, donc vous devriez en voir un si vous voulez être certain que votre texte de licence tient devant un tribunal.
Généralement, compiler votre code en C ne garantit pas un plus grande rapidité d'exécution. C'est parce que, à part quelques classes chanceuses dans lesquelles beaucoup de types peuvent être déclarés comme natifs, l'environnement d'exécution de Perl est toujours présent et donc vos programmes prendront autant de temps d'exécution et auront la même taille. Pour la plupart des programmes le gain de temps est légèrement supérieur au temps de compilation, l'exécution étant au mieux 10 à 30 % plus rapide. Le gain peut être significatif (plusieurs fois plus rapide) pour quelques rares programmes, mais c'est seulement au prix d'une modification importante de votre code.
Vous serez probablement étonné de savoir que la version actuelle du compilateur génère à partir de votre script un code compilé dont l'exécutable est tout simplement aussi gros que l'exécutable Perl lui-même. C'est parce que, tel que c'est fait actuellement, tous les programmes sont préparés pour utiliser toute la gamme eval(). Vous pouvez réduire cette taille en reconstruisant la librairie partagée libperl.so et la relier. Voyez le fichier pod INSTALL dans le répertoire du source de Perl pour plus de détails. Si vous liez votre binaire perl principal avec ceci, il sera minuscule. Par exemple, sur le système d'un auteur, /usr/bin/perl a une taille de seulement 11k !
En général, le compilateur ne fait rien pour rendre un programme Perl plus petit, plus rapide, plus portable, ou plus sécurisé. En fait, il va généralement aggraver tout cela. L'exécutable sera plus gros, votre VM system prendra plus de temps à charger l'ensemble, le fichier binaire sera fragile, et difficile à stabiliser, et la compilation n'a jamais arrêté le piratage de logiciels. Le véritable avantage du compilateur est plutôt la compacité, et quand vous aurez vu la taille de ce qui est généré (bon, à moins que vous n'utilisiez une librairie partagée libperl.so), vous voudrez probablement une installation complète de Perl de toute façon.
extproc perl -S -your_switches
comme première ligne dans le fichier "*.cmd" ("-S" est dû à un bug dans le handle 'extproc' de cmd.exe). Pour DOS, quelqu'un devrait d'abord inventer un fichier batch similaire et le codifier dans "ALTERNATIVE_SHEBANG" (voir le fichier INSTALL dans la distribution pour plus d'informations).
L'installation sur Win95/98/NT, avec le portage Perl de ActiveState, va modifier la table de registre pour associer l'extension ".pl" avec l'interpréteur perl. Si vous utilisez un autre portage, peut-être même en compilant votre propre Perl Win95/98/NT à l'aide d'une version Windows de gcc (e.g. avec cygwin ou mingw32), alors vous devrez modifier la base de registres vous-même. En plus d'associer ".pl" avec l'interpréteur, les gens sous NT peuvent utiliser "SET PATHEXT=%PATHEXT%;.PL" pour qu'ils puissent exécuter le programme "install-linux.pl" en tapant simplement "install-linux".
Les programmes Perl sur Macintosh auront le Créateur et le Type appropriés, un double-clic dessus appellera donc l'application Perl.
IMPORTANT! : Quoi que vous fassiez, SURTOUT ne vous contentez pas seulement d'installer votre interpréteur dans votre répertoire cgi-bin, pour faire fonctionner votre serveur web avec vos programmes. C'est un ÉNORME risque de sécurité. Prenez le temps de bien vérifier que tout fonctionne correctement.
# Additionner le premier et lz dernier champs
perl -lane 'print $F[0] + $F[-1]' *
# Identifier des fichiers-textes
perl -le 'for(@ARGV) {print if -f && -T _}' *
# enlever la plupart des commentaires d'un programme C
perl -0777 -pe 's{/\*.*?\*/}{}gs' foo.c
# Rajeunir un fichier d'un mois
perl -e '$X=24*60*60; utime(time(),time() + 30 * $X,@ARGV)' *
# Trouver le premier uid non utilisé
perl -le '$i++ while getpwuid($i); print $i'
# Afficher des chemins raisonnables vers des répertoires man
echo $PATH | perl -nl -072 -e '
s![^/+]*$!man!&&-d&&!$s{$_}++&&push@m,$_;END{print"@m"}'
OK, le dernier n'est pas très simple. :-)
Par exemple :
# Unix
perl -e 'print "Hello world\n"'
# DOS, etc.
perl -e "print \"Hello world\n\""
# Mac
print "Hello world\n"
(then Run "Myscript" or Shift-Command-R)
# VMS
perl -e "print ""Hello world\n"""
Le problème est que rien de cela n'est sûr : cela dépend de l'interpréteur de commande. Sous Unix, les 2 premiers marchent presque toujours. Sous DOS c'est bien possible qu'aucun ne fonctionne. Si 4DOS était l'interpréteur de commandes, vous auriez probablement plus de chances avec ceci :
perl -e "print <Ctrl-x>"Hello world\n<Ctrl-x>""
Sous Mac, cela dépend de l'environnement que vous utilisez. Le shell MacPerl ou MPW, ressemble plutôt aux shells Unix car il accepte pas mal de variantes dans les apostrophes, guillemets, etc, excepté qu'il utilise librement les caractères de contrôle Mac non ASCII comme des caractères normaux.
L'usage de qq(), q() et qx(), à la place de ``guillemets'', d'apostrophes' et d'`accents graves peut rendre les programmes sur une ligne plus faciles à écrire.
Il n'y a pas de solution globale à tout cela. Il y a un manque, purement et simplement. Embêté d'être loin d'Unix, hein ? :-)
[Kenneth Albanowski a contribué à certaines de ces réponses.]
FAQ sur la Securité du WWW
http://www.w3.org/Security/Faq/
FAQ Web
http://www.boutell.com/faq/
FAQ CGI
http://www.webthing.com/tutorials/cgifaq.html
Specificités HTTP
http://www.w3.org/pub/WWW/Protocols/HTTP/
Spécificités HTML
http://www.w3.org/TR/REC-html40/
http://www.w3.org/pub/WWW/MarkUp/
Spécificités CGI
http://www.w3.org/CGI/
FAQ sur la Sécurité des CGI
http://www.go2net.com/people/paulp/cgi-security/safe-cgi.txt
perl program 2>diag.out
splain [-v] [-p] diag.out
ou modifiez votre programme pour qu'il vous explique les messages :
use diagnostics;
ou
use diagnostics -verbose;
Quand il a été inclus comme partie intégrante de la Distribution Standard de Perl ou de sa documentation (écrite ou autre), ce travail a été couvert par la Perl's Artistic Licence. Pour des distributions séparées de tout ou partie de cette FAQ en dehors de celle-ci, voyez perlfaq.
Indépendante de cette distribution, tous les codes d'exemple ici, sont du domaine public. Vous êtes autorisé et encouragé à les utiliser tels quels ou de façon dérivée dans vos propres programmes, pour le fun ou pour le profit, comme vous le voulez. Un simple commentaire signalant les auteurs serait bien courtois, mais n'est pas obligatoire.