Was sind die best-practices für die Umsetzung ist ein CLI-tool, das in Perl?

Ich bin Implementierung eines CLI-Tools mit Hilfe von Perl.
Was sind die best-practices können wir hier Folgen?

  • Irgendwelche Hinweise, zu lernen über das schreiben von CLI-tools in Perl oder in einer anderen Sprache ?
InformationsquelleAutor Anandan | 2009-07-26
  1. 36

    Als Vorwort, ich habe 3 Jahre engineering und die Implementierung einer ziemlich komplizierten Kommandozeilen-Tools in Perl für eine große Finanz-Unternehmen. Die Ideen unten sind quasi ein Teil von unserem team-design-Richtlinien.

    Benutzeroberfläche

    1. Kommandozeilen-option: ermöglichen Sie so viele wie möglich haben default-Werte.

    2. KEINE positions-Parametern für einen Befehl mit mehr als 2 Optionen.

    3. Haben lesbaren Optionen Namen. Wenn die Länge der Kommandozeile ist ein Anliegen für nicht interaktive Aufruf (z.B. einige un-named legacy-Oberteile haben kurze Grenzen, die auf Kommando-Zeilen), bieten kurze alias - GetOpt::Long ermöglicht es, dass einfach.

    4. Zumindest, drucken Sie alle Optionen' Standard-Werte '-help' angezeigt wird.

      Besser noch, drucken Sie alle Optionen " "aktuelle Werte" (z.B. wenn ein parameter und ein Wert geliefert werden, zusammen mit "-Hilfe", die Hilfe-Nachricht gedruckt wird parameter s-Wert von der Kommandozeile). So können die Menschen versammeln Befehlszeilen-Zeichenfolge für die komplizierten Befehl, und bestätigen Sie es durch Anhängen von "-Hilfe", bevor Sie tatsächlich ausgeführt wird.

    5. Folgen Unix-standard-Konvention zu verlassen mit return-code ungleich null, wenn das Programm beendet mit Fehler.

    6. Wenn Ihr Programm produzieren nützlich (z.B. Wert-capturing/grepping/whatnot) Ausgabe, stellen Sie sicher, dass alle Fehler/Diagnose-Meldungen gehen an STDERR, so dass Sie leicht trennbar.

    7. Ideal, dem Benutzer zu ermöglichen, geben Sie input/output-Dateien über Kommandozeilen-parameter, stattdessen zwingen "<" /">" leitet - dies ermöglicht VIEL einfacher das Leben für Menschen, die komplizierte Rohre mit deinem Befehl. Das gleiche gilt für Fehlermeldungen - habe logfile-option.

    8. Wenn ein Befehl hat den Nebeneffekt, dass ein "whatif/no_post" - option ist in der Regel eine Sehr Gute Idee.

    Umsetzung

    1. Wie bereits erwähnt, nicht das Rad neu zu erfinden. Verwenden Sie standard-command-line-parameter-handling-Module - MooseX::Getopt, oder Getopt::Long

    2. Für Getopt::Long, weisen alle Parameter, um einen einzigen hash im Gegensatz zu den einzelnen Variablen. Viele nützliche Muster sind vorbei, dass CLI args hash-Objekt-Konstruktoren.

    3. Sicherstellen, dass Ihre Fehlermeldungen sind klar und informativ... E. g. include "$!" in jedem IO-Verwandte Fehlermeldungen. Es lohnt sich zu verausgaben extra 1 minute und 2 Zeilen in Ihrem code eine eigene "Datei nicht gefunden" vs. "Datei nicht lesbar" - Fehler, im Gegensatz zu verbringen 30 Minuten in der Produktion Dringlichkeit, weil eine nicht lesbare Datei Fehler wurde falsch diagnostiziert, indem Sie die Produktion Operationen, die als "No input file" - dies ist ein Beispiel aus der Praxis.

    4. Nicht wirklich CLI-spezifisch, aber überprüfen Sie alle Parameter im Idealfall direkt nach dem erhalten Sie.
      CLI-nicht für ein "front-end" Validierung webapps tun, so super besonders aufmerksam sein.

    5. Werden, wie oben diskutiert, Modularisieren business-Logik. Unter anderen Gründen bereits aufgeführt, ist die Höhe der Zeit, die ich hatte, zu re-implementieren einer vorhandenen CLI-tool als web-app ist gewaltig - und nicht, dass schwierig, wenn die Logik ist schon ein richtig perm Modul.

    Interessante links

    CLI-Design-Muster - ich denke, das ist die ESR ist

    Ich werde versuchen, fügen Sie mehr Kugeln, wenn ich mich Recht erinnere.

    InformationsquelleAutor DVK
  2. 21

    POD verwenden, um Ihr Dokument-tool, befolgen Sie die Richtlinien der man-pages; mindestens aus folgenden Abschnitten: NAME, SYNOPSIS, DESCRIPTION, AUTOR. Sobald Sie die richtige POD erzeugen Sie die man-Seite mit pod2man, Lesen Sie die Dokumentation auf der Konsole mit perldoc your-script.pl.

    Verwenden ein Modul, mit der Befehlszeilen-Optionen für Sie. Ich mag es wirklich, mit Getopt::Long in Verbindung mit Pod::Usage diese Weise aufrufen --help zeigt eine schöne Meldung.

    Stellen Sie sicher, dass Ihre Skripte gibt eine richtige Ausfahrt Wert, wenn es erfolgreich war oder nicht.

    Hier ist ein kleines Skelett von einem Skript, das alle diese:

    #!/usr/bin/perl

=head1 NAME

simplee - simple program

=head1 SYNOPSIS

    simple [OPTION]... FILE...

    -v, --verbose  use verbose mode
    --help         print this help message

Where I<FILE> is a file name.

Examples:

    simple /etc/passwd /dev/null

=head1 DESCRIPTION

This is as simple program.

=head1 AUTHOR

Me.

=cut

use strict;
use warnings;

use Getopt::Long qw(:config auto_help);
use Pod::Usage;

exit main();

sub main {

    # Argument parsing
    my $verbose;
    GetOptions(
        'verbose'  => \$verbose,
    ) or pod2usage(1);
    pod2usage(1) unless @ARGV;
    my (@files) = @ARGV;

    foreach my $file (@files) {
        if (-e $file) {
            printf "File $file exists\n" if $verbose;
        }
        else {
            print "File $file doesn't exist\n";
        }
    }

    return 0;
}
    • Ich glaube nicht, dass dies alles Händeringen über exit-Werte ist eine gute Idee. Perl bietet eine implizite exit(0) in Ermangelung einer Ausfahrt oder zu sterben. Wenn Sie sterben, wenn etwas falsch ist, und tun nichts besonderes, andernfalls bekommen Sie ein gut erzogener Programm. Ich denke, das Skelett würde verbessert werden, durch Notwasserung main ganz. Perl ist nicht C.
    • Der Grund für die wichtigste Funktion, die macht es Aussehen viel wie ein C-Programm ist, dass es ohne alle Variablen, die Sie erklären würde, in Ihrem Programm würde sich die Globale lexikalisch scoped Variablen. Mit dem "main" - Funktion werden alle inneren Variablen stammen aus dem Bereich, dass einzelne Funktion.
    • Uh, who cares? Es gibt keine anderen Bereiche sowieso. (Aber egal, das ist eine Menge code zu schreiben, nichts zu tun. Warum nicht MooseX::Getopt mit MooseX::Lauffähig? Dann das ganze script ist noch nicht einmal nötig!)
    • Ich denke, dass jemand mit "strenge" kümmern sollte, den Umfang Ihrer Variablen. Hier ist ein Beispiel, warum einige vielleicht wie legen Sie den gesamten code in eine Funktion. Vorstellen, dass das ganze Programm nicht isoliert, seine Variablen in einem lexikalischen Bereich eine neue Funktion Hinzugefügt. Wenn eine variable in der neuen Funktion nicht deklariert eine variable mit "mein" und es existiert in der übergeordneten Geltungsbereich diese verursachen eine Menge Kopfschmerzen. In dieser situation auch "use strict" nicht helfen kann. Der Grund ist, weil das Programm hat alle seine Variablen zu globalen lexikalische Variablen in der Datei.
    • "Wenn eine variable in der neuen Funktion nicht deklariert eine variable mit 'meinem'" - Wenn Ihre Funktionen nicht lokalisieren Ihre Variablen, bist du schon etwas falsch, und schreiben ein main Unterprogramm wird Ihnen nicht helfen, es wird nur die Tatsache verbergen, dass der code falsch ist.
    • Manchmal kann man vergessen, zu schreiben, meine vor eine variable (wegen Umgestaltung, etc). Es bedeutet nicht, dass der code fehlerhaft ist. In solchen Situationen Perl finden Sie eine variable in einem äußeren block und verwenden Sie es. Wie es oder nicht, alle Variablen, die in einem normalen perl-Skript, das nicht im block werden Globale Variablen in der Datei. Sie können dies ignorieren und so tun, dass mit Kleinbuchstaben, Namen sagen perl, die nicht als Globale Variablen, aber es wird nicht. Ich benutze einen main-block für diesen Zweck.

    InformationsquelleAutor potyl
  3. 12

    Einige Lektionen, die ich gelernt habe:

    1) verwenden Sie Stets Getopt::Long

    2) helfen, die auf der Nutzung via --help, idealerweise mit Beispielen von gemeinsamen Szenarien. Es hilft den Menschen nicht kennen oder vergessen haben, wie das tool zu verwenden. (I. e., Sie in sechs Monaten).

    3), es sei denn, es ist ziemlich offensichtlich, an den Benutzer, wie, warum, dann nicht für lange Zeit (>5s) ohne Ausgabe an den Benutzer. So etwas wie " print "Zeile $Zeile...\n" unless ($Zeile % 1000)' geht ein langer Weg.

    4) Für lang laufende Operationen, die dem Benutzer erlauben, sich zu erholen, wenn möglich. Es saugt wirklich durch zu bekommen 500k von einer million, zu sterben, und wieder von vorne anfangen.

    5) Trennen Sie die Logik von dem, was du tust in Module und verlassen Sie die eigentlichen .pl-Skript als barebones wie möglich; parsing-Optionen, Anzeige-Hilfe, aufrufen der grundlegenden Methoden, etc. Sie sind unvermeidlich, um etwas zu finden, das Sie wiederverwenden möchten, und dies macht es verdammt viel einfacher.

    • 3), immer bieten dem Benutzer die -q option aus, leise zu sein
    • #3 ist nur sinnvoll für Programme, die nicht im batch-Modus ausgeführt
    InformationsquelleAutor Bill
  4. 5

    Den wichtigsten Sache ist standard-Optionen.

    Versuchen Sie nicht, clever zu sein, einfach im Einklang mit bereits vorhandenen tools.

    Wie um dies zu erreichen ist auch wichtig, aber kommt nur zweiten.

    Eigentlich ist dies ziemlich generisch für alle CLI-Schnittstellen.

    InformationsquelleAutor Steve Schnepp
  5. 5

    Gibt es ein paar Module auf CPAN zu machen, dass schreiben CLI-Programme viel einfacher:


    Wenn Sie app ist der Elch auch einen Blick auf MooseX::Getopt und MooseX::Runnable

    • +1. Jeder andere Weg ist viel redundante Arbeit.
    • das macht die tab-Vervollständigung für Befehl-Ausführung??
    • Diese Module helfen Ihnen bei der Erstellung von Perl-Anwendungen werden als von der shell/CLI. Dein Kommentar scheint zu sein, zeigt auf eine andere Frage zu dem, was alle die hier bisher geantwortet haben. Wenn Sie Frage ist "wie zu emulieren CLI" dann würde ich Ihnen empfehlen, sich eine neue Frage und/oder auf der Suche auf CPAN Module IO::Prompt. Hoffe, das hilft?
    InformationsquelleAutor draegtun
  6. 4

    Die folgenden Punkte sind nicht spezifisch für Perl, aber ich habe gefunden, dass viele Perl-CL-Skripte auf einen Mangel in diesen Bereichen:

    1. Gängigen Kommandozeilen-Optionen. Zeigen Sie die Versionsnummer implementieren -v oder --version nicht --ver. Für rekursive Verarbeitung -r (oder-vielleicht -R, obwohl in meinem Gnu/Linux-Erfahrung -r ist häufiger) nicht-rec. Die Menschen mit Ihrem Skript, wenn Sie sich erinnern können die Parameter. Es ist leicht zu lernen einen neuen Befehl, wenn Sie sich erinnern können "es funktioniert wie grep" oder eine andere vertraute-Dienstprogramm.

    2. Viele Kommandozeilen-tools Prozess "Dinge" (Dateien oder Verzeichnisse) innerhalb der "aktuellen Verzeichnis". Während dies kann praktisch sein, stellen Sie sicher, dass Sie auch hinzufügen, Kommandozeilen-Optionen explizit für die Identifizierung der Dateien oder Verzeichnisse zu verarbeiten. Dies macht es einfacher, um Ihre Nützlichkeit in eine pipeline ohne die Entwickler haben für die Ausgabe einer Reihe von cd-Befehlen und erinnern Sie sich, in welchem Verzeichnis Sie sich befinden.

    InformationsquelleAutor benrifkah
  7. 2

    Sollten Sie verwenden Perl-Module zu machen den code wiederverwendbar und leicht zu verstehen.

    sollten Sie einen Blick auf Perl best practices

    InformationsquelleAutor sud03r
Schreibe einen Kommentar