Avant que vous commenciez...
Liberté totale – et assez de possibilités pour des problèmes
Perl vous laisse tout latitude dans sa configuration fondamentale. On peut,
comme à l'époque du BASIC, utiliser des variables et leur assigner quelque
valeur sans que Perl soit au fait desquelles au début. On pourrait supposer
qu'il ne constitue aucun problème parce qu'on va utiliser seulement ces
variables qu'on a défini antérieurement, mais lorsqu'on faisait une faute de
frappe quelque part?
Il y a des erreurs difficilement à découvrir comme résultat qui pourrait vous
faire perdre la raison. Il pourrait se passer que quelque condition dont on
sait qu'elle est satisfait dans certains prérequises ne soit jamais déclenchée
- ou déclenche toujours bien que les conditions ne sont pas stisfaits du tout.
Lorsque votre script montre ces symptômes, vous avez fait à tous les coups une
faute de frappe quelque part, soit les définitions de variables, soit
l'uultérieure interrogation en question n'importe où.
Ce code Perl va expliciter ce problème:
Ici on définit une variable dont contenu il faut dépenser. La ligne qui faut faire la dépense contient une faute de frappe: D'une part la variable utilisée ici n'est pas défini du tout, et d'autre part une variable non défini contient implicitement la valeur undef qu'il faut dépenser ici. Mais Perl ne va jamais criticailler ces deux problèmes par défaut – qui a pour conséquence que des fautes qui font des compilateurs ou interpréteurs des autres langages informatiques râler, conduisent aux effets secondaires totalement insoupçonnées.
Des variables avec des contenus indéfini constituent des autres problèmes que
conduisent aux erreurs, parce que des données nécessaires ne sont pas
disponibles du tout. Au lieu de cela on va s'étonner de résultats que le script
fournit.
Une troisième sources d'erreurs sont des entrées d'utilisateur. Comme on
normalement voudrait prendre cela trop à la légère et donc n'implémente pas des
vérifications importantes, il pourrait se passer qu'on accepte des entrées
d'utilisateur non vérifiées – pour que quelque utilisateur malintentionné
pourrait donc passer des entrées que font le script faire quelque chose imprévu
qu'il n'a jamais du faire.
Ils sont les vérifications insuffisantes qui constituent le point faible numéro
1 concernant des entrées d'utilisateur. Donc une entrée qui serve à demander
une base de données MySQL pourrait être construit à une façon que passe des
additionelles commandes MySQL au script dont il va exécuter aussi. L'opérateur
du serveur affecté se demandera ensuite pourquoi la base de données sera
détruit ou – pire – des données confidentielles seront dérobées et des
étrangers totals gagnaient d'accès aux zones du serveur où il n'ont rien à
faire.
Mais Perl offre assez d'options pour éviter la plupart des problèmes.
Détecter des potentiels problèmes
Lorsque vous écrivez un script Perl, vous allez normalement le commencer avec
#!/usr/bin/perl (cherchez pour l'interpréteur Perl
avec where perl si le chemin d'accès diffère de cet
exemple et donnez le chemin correct au lieu de cela). Le système donc sait
qu'il faut utiliser un autre logiciel que traduit le script pour que vous
puissiez vous épargner démarrer Perl explicitement.
A sa configuration fondamentale Perl est bien taciturne, et vous recevrez de
peu à aucune réaction sauf des erreurs de traduction obvies lorsqu'il y a
quelque chose qui cloche et le problème n'est pas assez grave pour Perl de
l'interrompre. Pour connaître plus, il faut activer les avertissements de Perl.
Vous allez l'atteindre par compléter l'invocation de l'interpréteur Perl pour
qu'il apparaît comme suivant:
#!/usr/bin/perl -w.
Maintenant si Perl trébuche sur quelque chose potentiellement problématique, il
va dépenser un avertissement même si le script n'est pas interrompu. Vous
toutefois recevez une indication sur des éventuels problèmes, donc des
problèmes inexplicables deviennent moins inexplicable tout à coup.
Lorsqu'on change l'exemple ci-dessus, on obtient le code suivant:
Lorsqu'on exécutera ce code, Perl dépensera ceci:
Ah! Maintenant Perl devient plus communicatif: Perl nous fait savoir qu'il a
découvert deux variables ($test et
$tset) dont les deux sont utilisées une seule fois
et en plus il faut dépenser une valeur indéfini par
$tset.
Ça nous montre des repères qu'il y a quelque chose qui cloche et où il faut
chercher pour des erreurs. Seul bémol: Le script est encore exécuté, produisant
des effets secondaires non désirés.
Prévenir des noms de variables faussement écrits
Ceci est l'autre majeure source d'erreur dans un script Perl. Lorsqu'il est
comparativement court, on peut découvrir des fautes d'écriture très rapidement
la plupart de temps, mais si le script devient plus long et donc plus complex,
c'est une autre paire de manches. On y a besoin de la méthode conventionelle,
soit imprimer l'entier script et le chercher pour des erreurs «à pied», si ce
n'est qu'on risque encore manquer des autres. Il donc faut une autre mßethode,
mais Perl vient en aide à nous: Simplement incluez la ligne suivante:
use strict;
Ensuite on obtient le code suivant:
Exécuter ce code produira ça:
Cette directive force Perl à accepter seulement les variables qu'on a définit explicitement antérieurement. Parce qu'on n'a rien de tel fait, Perl se plaindra tout de suite, parce qu'il découvre une faute ici. Donc on déclare explicitement la variable $test. Perl y prévoit le mot-clé my. Le code donc modifié apparaît comme suivant:
Exécuter ce code produira ceci:
On a éliminé le message d'erreur pour la déclaration comme ça, mais Perl râle encore à la ligne contenant la sortie. On a donc trouvé cette source d'erreur et peut l'éliminer. Lorsqu'on corrige cette erreur et exécutera le script encore une fois, il dépense ceci:
Afin le script est opérationnel et vous pouvez l'utiliser sans problèmes. Qui
apparaît facile dans cet exemple pourrait devenir un véritable jeu de piste
dans un script complexe, en particulier lorsqu'il y a une erreur à une place
embrouillée ou on voit seulement ce qu'on veut voir à force du code et donc
manquera des fautes d'écriture.
Si on a ordonné Perl à faire attention aux tels problèmes, il va vous les
signaler et complètement interrompre compiler le script si nécessaire. On
obtient en outre une kyrielle de messages d'un grand secours pour que des
fautes qui sont difficiles à trouver deviennent très évidemment tout à coup et
donc sont facilement réparables.
Ceci va calmer le frayeur des fautes difficile à trouver.
Le mode impur
Tandis que les deux facultés mentionnées ci-dessus servent de découvrir le pot
aux roses entre des éventuelles fautes et donc réparer des éventuels erreurs
de fonctionnement, cette méthode couvre une autre part qui devient important
quand le script est en cours, mais peut aussi conduire aux erreurs de
fonctionnement: On parle des entrées d'utilisateur.
Parce qu'il y a encore et toujours quelconques idiots qui abusent un script
qui attend des entrées d'utilisateur, il faut corriger ces entrées
d'utilisateur à une façon pour qu'on ne peut plus faire des bêtises.
Le mode impur du Perl y
entre en jeu qui marque toutes entrées d'utilsateur comme non fiable. Il n'est
aucun problème tant qu'on les utilise seulement dans le script soi-même parce
qu'ils servent comme point de départ pour des calculs et al. et donc ne peuvent
pas causer de malheur. Seulement si on voudrait utiliser ces données pour
exécuter des opérations potentiellement dangereuses (p. ex. pour ouvrir un
fichier dans lequel on veut inscrire des données) Perl va avorter par signaler
une erreur. D'abus d'un script perl est donc facilement empêché.
Pour rendre ces données utilisable, il faut les «nettoyer» en un premier temps,
soit éliminer toutes parts qui constituent un problème et utiliser les données
entièrement vérifiées. Vous y pouvez assurer que rien ne va pas louper même
si on a besoin des interactions avec des utilisateurs.