Perl est un langage de programmation créé par Larry Wall en 1987 (Artistic License et GPL). La version 5.44.0 est parue le 15 juillet 2026. La précédente 5.42.0 était initialement parue en juillet 2025, avec un dernier correctif 5.42.2 publié en mars 2026.
Parmi les améliorations principales :
- paramètres nommés dans les signatures
- foreach avec plusieurs variables peuvent maintenant utiliser des alias de références
- fonctionnement amélioré des motifs d’expressions régulières avec /xx
- prise en charge d’Unicode 17.0
- nouvelle source d’entropie pour l’initialisation du générateur de nombres pseudo-aléatoires
Mais aussi 3 correctifs sécurité, quelques incompatibilités, des améliorations de performances, de documentation, etc. Reportez-vous aux notes de version pour avoir tous les détails. La suite de la dépêche décrit les améliorations principales et les correctifs sécurité.
Améliorations principales
Paramètres nommés dans les signatures
Cette version de Perl apporte la possibilité de passer des paramètres de fonction par paire nom/valeur plutôt que par position.
sub f ($x, $y, :$alpha, :$beta = undef) { ... }
f( 123, 456, alpha => 789 );Cette fonctionalité est considérée comme étant experimentale et est décrité en détail dans la partie "Signatures" de perlsub.
Les foreach avec plusieurs variables peuvent maintenant utiliser des alias de références
Perl version 5.22 avait apporté des alias à des références, permettant à la variable d’itération d’une boucle foreach de créer de nouveaux alias à une référence. Avec Perl 5.36, on pouvait itérer sur plusieurs variables à la fois dans une boucle foreach. Dans cette version de Perl, ces deux fonctionnalités peuvent être utilisées ensemble, ce qui permet d’avoir plusieurs variables d’itération, certaines pouvant être des alias de références.
use v5.44;
use feature qw( refaliasing declared_refs );
my %hash = (
one => [1],
two => [2, 2],
);
foreach my ( $key, \@items ) ( %hash ) {
say "The $key array contains: @items";
}Fonctionnement amélioré des motifs d’expressions régulières avec /xx
À titre expérimental, le modificateur de motif /xx permet aux classes de caractères (par exemple, [a-zA-Z]) de s’étendre sur plusieurs lignes et de contenir des commentaires ; il signale également les cas potentiels où une partie du motif a été interprétée comme un commentaire au lieu de l’interprétation voulue. Ce comportement est activé par la directive use feature "enhanced_xx". Voir la section « /x et /xx » dans la documentation perlre.
Prise en charge d’Unicode 17.0
Le support Unicode de Perl passe à la version 17.
Nouvelle source d’entropie pour l’initialisation du PRNG
Perl utilise désormais l’appel système getentropy() pour obtenir des octets aléatoires adaptés à l’initialisation de son PRNG interne. Auparavant, Perl lisait des octets bruts depuis le périphérique /dev/urandom. Perl procède désormais à cette initialisation dans l’ordre suivant (en passant à l’étape suivante en cas d’échec) :
-
getentropy()sur les systèmes prenant en charge cet appel (Linux, BSD, macOS) -
/dev/urandomsur les systèmes qui en disposent - Une empreinte (hash) de variables d’état internes : temps Unix, identifiant de processus et valeur de pointeur
Notez que le PRNG interne ne convient toujours pas aux applications nécessitant une sécurité élevée. Consultez la section « rand EXPR » dans perlfunc pour les aspects liés à la sécurité.
Securité
CVE-2026-8376 - Débordement de tampon dans Perl_study_chunk
La fonction Perl_study_chunk, située dans regcomp_study.c, vérifiait la taille du tampon de sous-chaîne concaténée en nombre de caractères plutôt qu’en octets. Dans une version 32 bits, ceci peut entraîner un débordement de tampon, provoquant des écritures hors limites.
CVE-2026-57432 - Débordement de tampon dans S_measure_struct
Si l’on appelle pack ou unpack pour traiter une structure dont la taille calculée est trop importante pour tenir en mémoire, un dépassement d’entier peut arriver et entraîner un débordement de tampon. Ce cas de figure se produit généralement lorsque l’on utilise un nombre élevé comme facteur de répétition pour un élément.
CVE-2026-13221 - Regex trie 16-bit field overflow
L’optimisation de type « trie » (arbre de recherche) du moteur d’expressions régulières pouvait subir un dépassement lors du traitement d’une alternance comportant plus de 65 000 branches. Cela pouvait entraîner à la fois des faux positifs et des faux négatifs pour ces expressions régulières.
Aller plus loin
- Perl sur Wikipedia (30 clics)
- Guide Perl - Débuter et progresser en Perl (25 clics)
- L'association Les Mongueurs de Perl (20 clics)
- Perl 5.44.0 Release notes (23 clics)
# La fin des goto
Posté par smonff (site web personnel, Mastodon) . Évalué à 7 (+7/-0).
À noter également le changement sur les
goto(décrit comme "create spaghetti code" par la documentation officielle, et déprécié depuis la version5.12). Traduction approximative:goto LABEL;lance maintenant une exception lorsque il tente de passer dans le corps d'une boucle, ou depuis l'extérieur de tout autre bloc. Par exemple:lance une exception indiquant que ce comportement n'est plus permis dorénavant.
Je dis bon débarras, car j'en vois encore être introduit dans du code récent.
[^] # Re: La fin des goto
Posté par Emmanuel Seyman . Évalué à 6 (+5/-0).
À noter que goto a toujours été désigné comme une instruction à éviter en Perl et qu'il n'est là que pour permettre le portage de code C (ou Awk ?) sans trop de difficultés.
[^] # Re: La fin des goto
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
À noter aussi que le Go To n’est pas interdit en soi, c’est juste un/e usage/construction tordu/e qui est détecté/e et prohibée : ça n’a pas de sens, hormis celui de gâchette de l’apocalypse, que de sauter dans une boucle quelque soit la raison.
"It is seldom that liberty of any kind is lost all at once." ― David Hume
# Perl toujours vivant !
Posté par Bernie . Évalué à 9 (+9/-0).
Bonne nouvelle ! Ayant beaucoup écrit en Perl vers le milieu des années 90 jusqu'à la fin de ma carrière il y a déjà quelques années, je trouve sympa que le langage évolue encore. Et trouve dommage qu'il semble passé de mode auprès de beaucoup de (jeunes) développeurs ; est- il d'ailleurs encore enseigné en école ?
[^] # Re: Perl toujours vivant !
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+1/-1).
Personnellement je ne trouve pas ça dommage du tout. Ce langage m'a toujours donné l'impression d'être un truc extraterrestre. J'ai même du mal à comprendre comment il a pu être si populaire il y a une ou deux décennies.
Les introductions à Perl que j'ai pu lires mentionnaient toujours le fait qu'il avait été conçu par un linguiste, comme si c'était un avantage. Je n'en suis pas convaincu. ;-)
[^] # Re: Perl toujours vivant !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 10 (+12/-1).
Simple : le langage avait tous les atouts de ce qui existait quand il fut créé. Quand il fallait apprendre comment mixer AWK et CSh et d’autres outils, on était bien content de pouvoir le faire dans un seul langage d’une part et de pouvoir transposer rapidement ce que l’on connait des autres outils (sans devoir refaire une longue formation). De plus, malgré toutes les fonctionnalités offertes, le langage est rapide et flexible. Parant des fonctionnalités, les expressions rationnelles et les tableaux de hachage étaient un bonheur offert bien longtemps avant qu’on retrouve cela dans les langages qui ont la côte aujourd’hui...
Beaucoup de langages obligeaient à reformater sa façon de penser. Et là on a un langage qui est beaucoup plus proche de la façon de penser des gens qui n’ont pas fait d’études de logisticiens ou d’analystes-programmeurs. On ne se rend pas compte mais beaucoup des apports de PERL se retrouvent dans Ruby et Python que tu aimes bien. ;-)
Il ne faut pas spécifiquement regarder le fait que Larry soit linguiste mais plus le fait que ses connaissances de la discipline a permis d’apporter un vent frais dans la façon de concevoir et utiliser un langage de programmation. La démocratisation de ses idées font qu’on a du mal à voir aujourd’hui que ce soit un avantage à l’époque : c’est comme les gens qui tapent sur BASIC sans réaliser ce que c’était d’apprendre et utiliser ALGOL ou COBOL à l’époque. :-)
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Perl toujours vivant !
Posté par barmic 🦦 . Évalué à 7 (+5/-0).
Peut être que les lectures de ce qu’on produit les mongueurs de perl t’aidera à comprendre :
Je pense en particulier à https://articles.mongueurs.net/magazines/perles/perles-29.html, https://articles.mongueurs.net/magazines/perles/perles-38.html et https://articles.mongueurs.net/magazines/perles/perles-48.html. C’est un mélange de hacking (au sens originel), de ne pas être complètement perdu par rapport au C et d’un langage qui ne se met pas en travers de ton chemin pour ce que ça veut dire de meilleur comme du pire. C’est une sorte de chaînon entre le shell et un ruby/python qui se veulent plus carré. Comme tout langage il représente un mélange propre qui marche bien pour ceux qui veulent un outil qui fait plus que zsh, mais qui ne vient pas avec une opinion comme python.
Il avait aussi des qualités intrinsèques comme le fait que CPAN existait (1995) avant pypi (2002) et rubygem (2004).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Perl toujours vivant !
Posté par bistouille . Évalué à 6 (+4/-0).
Bonjour,
J'ai plussé le message bien qu'en désaccord partiel avec ce qui est écrit.
Perl était utilisé comme "langage-colle" pour du système/réseau bien avant que Python ne devienne très populaire.
C'était surtout intéressant en premier lieu pour remplacer des scripts combinant shell+awk+sed+grep+...
Aussi, on pouvait (on peut encore) faire des one-liners assez puissants en lieu et place d'enchaînements de commandes et de pipes.
Donc c'etait "mieux" sans doute (plus simple en tout cas) dans ce cas de figure.
Perl est aussi une arme à double tranchant, le "there's more than one way to do it" légendaire qui était fourni comme un "argument de vente" si je puis dire est devenu "there are too many ways to do it wrong".
Donc différentes écoles ont émergé pour pallier au bordel ambiant en créant des frameworks assez complets et ardus pour faire tout ce qui faisait ailleurs (des objets, de l'injection de dépendances, "higher order programming" comme titrait un bouquin de l'époque, etc...) et l'écosystème CPAN est devenu monstrueusment gros et redondant au fil du temps (ceci étant, nodejs et python sont un peu sur la même voie qui semble être une évolution inéluctable lorsque un certain niveau de popularité est atteint par tout langage).
Des idiômes Perl servaient de jalons pour séparer les débutant·e·s des expérimenté·e·s et ces derniers des gurus, avec une nuance de taille par rapport à d'autres langages, c'est que la communauté étaient assez bienveillante dans l'ensemble, notamment les "Perl Mongueurs" francophones, qui étaient très chaleureux et festifs dans les années 1990/2000.
Les "journées Perl" FR et les YAPC::Europe c'était quelquechose!
Ca me manque cet état d'esprit, ayant dû peu à peu renoncer à Perl dans mon activité professionnelle dans une culture différente et des choix techniques auxquels j'ai bien dû m'adapter.
Il faut bien reconnaître que quand je remets le nez par moment dans du vieux code Perl personnel, il me faut du temps pour me remettre dans le bain et comprendre ce que ça faisait, lutter contre l'autovivification des listes et tables de hâchage, me souvenir que $a et b ne sont pas des variables ordinaires, utiliser des eval {... } et des if (@) façon magie noire pour faire de la gestion d'exceptions... c'est quand même à la fois étrange et amusant (ou dérangeant selon les goûts).
Quoiqu'il en soit, ce langage a ses vertus et ses défauts, et il n'est pas mort même s'il est en très forte baisse d'utilisateurs par rapport aux années 2000, on peut faire des choses très concises rapidement, et bien qu'il soit utilisé dans de gros softs comme Requests Tracker mon opinion subjective est qu'il a plutôt sa place dans la boîte à outil du sysadmin "à l'ancienne" pour faire des "one-shot", des scripts courts et auto-suffisants en quelques lignes, ou les fameux "one-liners" pour faire du traitement par lot dans des tas de fichiers.
[^] # Re: Perl toujours vivant !
Posté par Hashment . Évalué à 3 (+3/-0).
En école d'ingénieur, c'est le langage Python qui est massivement utilisé pour :
En revanche le langage C est toujours enseigné en forensic pour démontrer/chatouiller les failles de sécurités.
Il est utilisé pour effectuer des attaques de buffer overflow, format string, etc ...
Il est enfin utilisé pour comprendre comment fonctionne, par exemple, un processus chargé en mémoire une fois le code binaire de ce dernier désassemblé et décompilé (ingénierie inverse).
[^] # Re: Perl toujours vivant !
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Python a souvent été utilisé par l'enseignement tout comme Pascal avant lui parce que contrairement à Perl, il n'y a pas 1000 manières de faire la même chose. Du coup c'est plus facile à corriger et moins susceptible de faire du caca, pour le prof c'est quand mēme un avantage par rapport à devoir être un gourou du language.
[^] # Re: Perl toujours vivant !
Posté par yinqi . Évalué à 6 (+5/-0).
Je n'ai jamais codé plus loin que quelques outils pour moi en perl, et le logiciel codé en Perl le plus abouti à mes yeux est Webmin qui a très bien évolué depuis que je l'ai utilisé à ses débuts, je m'y remets depuis peu pour mes besoins personnels. Je ne sais pas s'il y a toujours des bouts de Java dedans où si c'est 100% Perl.
En amateur de Regex, je vois que Perl est très puissant, et il est vrai qu'il semble plus utilisé en outil interne de logiciels qu'uniquement seul, on le retrouve à différents degrés dans OCS Inventory, APT/Dpkg, Nagios, GNOME, Sendmail, Git par exemple.
Mais utilisé tout seul pour BackupPC, MRTG aussi.
C'est donc outil puissant, un B2B des informaticiens, il semble donc important sinon vital d'y intéresser quelques uns des jeunes programmeurs.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.