Le traitement des arguments de la ligne de commande est effectué via le tableau intégré @ARGV, qui contient tous les paramètres passés au script lors de son exécution (à l'exception du nom même du script). C'est le moyen de base pour toutes les applications CLI Perl, mais il y a beaucoup de nuances liées aux types de données, à l'encodage, à la séparation des paramètres et aux pièges de la lecture automatique des fichiers.
Depuis les premières versions de Perl, le tableau @ARGV représentait le "point d'entrée" standard pour les arguments de lancement, similaire à argv[] en C. Cependant, Perl, étant un langage généraliste et de traitement de texte, a ajouté de nombreux comportements supplémentaires — par exemple, l'expression <>, qui est "liée" au contenu de @ARGV, permettant de lire immédiatement les fichiers répertoriés comme arguments.
La lecture triviale de @ARGV ne convient que pour des cas simples. Dans des programmes CLI complexes, la tâche de traitement des options (du type --help, -o fichier) émerge. Ici, une simple lecture des données par index devient dangereuse et peu pratique. De plus, cela devient encore plus compliqué avec le traitement des arguments contenant des espaces, des caractères non standards ou dans différents encodages. De plus, il y a des questions sur l'ouverture automatique des fichiers via l'opérateur <> et des comportements inattendus si les éléments de @ARGV sont égaux, par exemple, à "-" (stdin).
Lecture des arguments simples :
foreach my $arg (@ARGV) { print "Arg: $arg "; }
Généralement, pour les options, on utilise le module spécial Getopt::Long :
use Getopt::Long; my $help; GetOptions('help' => \$help);
Pour lire tous les fichiers de @ARGV, le contenu des fichiers peut être immédiatement lu via une boucle :
while (<>) { print; }
Que se passera-t-il si l'un des arguments de la ligne de commande contient uniquement un tiret (-) ?
Dans ce cas, en utilisant l'opérateur <>, Perl considère '-' comme l'entrée standard (stdin) et non comme le nom d'un fichier.
perl script.pl - file.txt # Lecture d'abord depuis stdin, puis depuis file.txt
Peut-on modifier @ARGV en toute sécurité à l'intérieur du script ?
Oui, c'est une pratique standard pour supprimer les arguments déjà traités. En général, après le traitement des options, @ARGV ne conserve que les "noms de fichiers bruts" ou les paramètres non reconnus.
Faut-il faire encode/décode lors du travail avec des arguments UTF-8 dans @ARGV ?
Cela dépend de la locale et de l'environnement. Par défaut, Perl ne modifie pas les encodages de @ARGV, mais les accepte "tels quels". Ainsi, si les noms de fichiers (ou les paramètres) contiennent des caractères non-ASCII, il est préférable de décoder explicitement les chaînes en utilisant Encode si un traitement ultérieur est nécessaire dans Perl.
Un utilitaire de parsing de logs accepte une liste de fichiers. L'utilisateur indique par inadvertance '-':
perl parse.pl - access.log
résultat — soudain, le programme est bloqué et attend une saisie au clavier.
Avantages :
Inconvénients :
Une application CLI lit les arguments via Getopt::Long, gérant explicitement toutes les options négatives, laissant dans @ARGV uniquement les noms de fichiers :
perl report.pl --input access.log --output report.txt
Avantages :
Inconvénients :