Antwort.

Die Verarbeitung von Befehlszeilenargumenten erfolgt über das eingebaute Array @ARGV, das alle Parameter enthält, die dem Skript beim Start übergeben werden (außer dem Namen des Skripts selbst). Dies ist der grundlegende Weg für alle CLI Perl-Anwendungen, aber es gibt viele Nuancen, die mit Datentypen, Kodierung, der Trennung von Parametern und den Fallstricken beim automatischen Lesen von Dateien zu tun haben.

Historie der Frage

Seit den ersten Versionen repräsentiert das Array @ARGV den Standard-"Einstieg" in die Startargumente, ähnlich wie argv[] in C. Allerdings hat Perl, als Sprache für allgemeine Zwecke und Textaufgaben, viele zusätzliche Tricks eingeführt – zum Beispiel der Ausdruck <>, der "verbunden" ist mit dem Inhalt von @ARGV, wodurch es möglich ist, Dateien, die als Argumente aufgeführt sind, sofort zu lesen.

Problem

Das triviale Lesen von @ARGV reicht nur für einfache Fälle aus. Bei komplexen CLI-Anwendungen entsteht die Herausforderung, Optionen zu verarbeiten (z.B. --help, -o file). Hier wird das einfache Lesen von Daten nach Indizes unsicher und unpraktisch. Es wird noch schwieriger, wenn Argumente Leerzeichen, nicht standardmäßige Zeichen oder unterschiedliche Kodierungen enthalten. Außerdem ergeben sich Fragen zur automatischen Öffnung von Dateien über den Operator <> und unerwartetem Verhalten, wenn Elemente von @ARGV gleich sind, z.B. "-" (stdin).

Lösung

Einfaches Lesen von Argumenten:

foreach my $arg (@ARGV) {
    print "Arg: $arg
";
}

Normalerweise werden für Optionen spezielle Module wie Getopt::Long verwendet:

use Getopt::Long;
my $help;
GetOptions('help' => \$help);

Um den Inhalt aller Dateien aus @ARGV zu lesen, kann man den Inhalt der Dateien sofort in einer Schleife lesen:

while (<>) {
    print;
}

Schlüsselmerkmale:

@ARGV — unverarbeitete Zeichenfolgen, alle Parameter nach dem Skriptnamen, einschließlich Dateipfade
Der Operator <> interpretiert @ARGV als Liste von Dateien zum Lesen
Für Optionen der Befehlszeile ist es vorzuziehen, Module wie Getopt::Long, Getopt::Std usw. zu verwenden.

Fangfragen.

Was passiert, wenn eines der Befehlszeilenargumente nur einen Bindestrich (-) enthält?

In diesem Fall interpretiert Perl bei Verwendung des Operators <> den '-' als Standard-Eingabe (stdin) und nicht als Dateinamen.

perl script.pl - file.txt
# Zuerst aus stdin lesen, dann aus file.txt

Kann man @ARGV innerhalb des Skripts sicher modifizieren?

Ja, das ist eine gängige Praxis, um bereits verarbeitete Argumente zu entfernen. In der Regel verbleiben nach der Verarbeitung von Optionen in @ARGV nur noch "nackte" Dateinamen oder nicht erkannte Parameter.

Muss man bei der Arbeit mit UTF-8-Argumenten in @ARGV encode/decode durchführen?

Das hängt von der Locale und der Umgebung ab. Standardmäßig konvertiert Perl die Kodierungen von @ARGV nicht, sondern akzeptiert sie "wie sie sind". Daher ist es ratsam, die Zeichenfolgen explizit mit Encode zu dekodieren, wenn man mit ihnen in Perl arbeiten möchte, falls die Dateinamen (oder Parameter) nicht-ASCII-Zeichen enthalten.

Typische Fehler und Anti-Muster

Manuelle Verarbeitung von Skriptoptionen — leicht, mit Positionsargumenten Fehler zu machen
Der Versuch, eine Binärdatei über <> zu lesen, führt zu Datenbeschädigung
Ignorierung der Notwendigkeit, Parameter bei Internationalisierung zu dekodieren

Beispiel aus dem Leben

Negativer Fall

Ein Tool zum Parsen von Logs akzeptiert eine Liste von Dateien. Der Benutzer gibt versehentlich '-' an:

perl parse.pl - access.log

Als Ergebnis bleibt das Programm plötzlich stehen und wartet auf Eingaben von der Tastatur.

Vorteile:

Schnelles Lesen aus stdin ist ebenfalls möglich.

Nachteile:

Unvorhersehbar für Anfänger-Benutzer
Schwer zu erklären, warum es "hängt"

Positiver Fall

Ein CLI-Programm liest Argumente über Getopt::Long und verarbeitet explizit alle negativen Optionen, wobei in @ARGV nur Dateinamen verbleiben:

perl report.pl --input access.log --output report.txt