Réponse

En Perl, les descripteurs de fichiers (filehandles) sont des objets spéciaux (variables globales ou lexicales) qui sont associés à un fichier physique ou virtuel. Il est très important d'ouvrir, de vérifier et de fermer correctement les fichiers afin d'éviter les fuites de ressources et les violations de sécurité.

Exemple de bon usage :

open my $fh, '<', 'myfile.txt' or die "Impossible d'ouvrir le fichier : $!";
while (my $line = <$fh>) {
    print $line;
}
close $fh or warn "Impossible de fermer le fichier : $!";

Détails :

• Il est conseillé d'ouvrir les fichiers en mode perl5 : utiliser un filehandle lexical (open my $fh, ...). Les descripteurs globaux (OPEN FILE, ...) sont considérés comme obsolètes.
• La vérification du succès de l'ouverture d'un fichier est OBLIGATOIRE. Utilisez toujours or die/or warn.
• Après utilisation, le fichier doit être fermé via close et les erreurs potentielles doivent être gérées.
• Pour les fichiers binaires, utilisez des couches : binmode $fh.
• Pour éviter des vulnérabilités, échappez toujours les variables dans les chemins et vérifiez les permissions.

Question piège

Quelle est la différence entre la construction open FH, ... et open my $fh, ..., et pourquoi est-il recommandé d'utiliser la deuxième option ?

Réponse : La construction open my $fh, ... crée un descripteur de fichier lexical, c'est-à-dire qu'il fonctionne uniquement dans le cadre du bloc/sous-programme actuel et est automatiquement détruit en dehors de la portée. Cela prévient le chevauchement accidentel des descripteurs, protège contre les conflits de noms des filehandles globaux et améliore la fiabilité.

open FH, '<', 'file.txt';    # Descripteur global ! À éviter.
open my $fh, '<', 'file.txt'; # Lexical, en toute sécurité.

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

---

Histoire

Dans un grand projet, l'utilisation de descripteurs globaux identiques (OPEN LOG, ...) était autorisée. En conséquence, des requêtes parallèles écrivaient accidentellement dans de mauvais fichiers, ce qui entraînait la perte ou le mélange des journaux.

---

Histoire

Un développeur a oublié de vérifier le succès de l'ouverture du fichier ; par conséquent, si le fichier n'existait pas, une erreur était écrite ailleurs (par exemple, les journaux étaient écrits au mauvais endroit, des fichiers étrangers étaient supprimés, etc.).

---

Histoire

L'absence d'appel à close entraînait l'épuisement des descripteurs sur le serveur lors d'un traitement massif de fichiers - le serveur commençait à "geler" et à planter sur de grands volumes de données.