Opened by pq at 2015-12-01 14:24
Ihr macht das viel zu kompliziert.
Der Name der jeweiligen Subklasse fürs Plugin wird auf der Kommandozeile übergeben. Du brauchst keine Konfigurationsdatei und schon gar nicht in YAML (son Schrott).
Demzufolge wird der Code für die Plugins auf Subklassen aufgeteilt. Der pure Aufruf der Framework-main ohne Argumente zeigt alle verfügbaren Subklasssn (Plugins) nur an, ohne die gleich zu kompilieren.
Sie werden erst kompiliert, wenn sich der Anwender für eine bestimmte Subklasse entschieden hat und die als erstes Argument übergibt. Beispiel:
anm.: Der Name des Plugins wird NICHT über Getopt gehandled.
Last edited: 2015-12-02 08:56:02 +0100 (CET)
Der Name der jeweiligen Subklasse fürs Plugin wird auf der Kommandozeile übergeben. Du brauchst keine Konfigurationsdatei und schon gar nicht in YAML (son Schrott).
Demzufolge wird der Code für die Plugins auf Subklassen aufgeteilt. Der pure Aufruf der Framework-main ohne Argumente zeigt alle verfügbaren Subklasssn (Plugins) nur an, ohne die gleich zu kompilieren.
Sie werden erst kompiliert, wenn sich der Anwender für eine bestimmte Subklasse entschieden hat und die als erstes Argument übergibt. Beispiel:
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
c,pl ist der Name der main (Framework)
>c.pl
zeigt alle verfügbaren Plugings und was die machen
zeige was Pligun RPC macht und welche Opts das braucht
D:\>c.pl RPC
Remote CMD auf dem Host
--base, -b: Name der Datenbank für Option --sql
--cat, -c: Den Inhalt einer Datei ausgeben
--destdir, -d: Zielverzeichnis für Upload mit --files
--files, -f: Lokale Dateien für Upload nach --destdir
--host, -h: example.de
--ls, -l: Entspricht dem Kdo. ls -ltr im aktuellen Pfad oder voll qual. angegeben
--perlversion, -p: Gibt die PerlVersion vom RemoteHost aus
--sql, -s: SQL Anweisung, erfordert --base
anm.: Der Name des Plugins wird NICHT über Getopt gehandled.
Last edited: 2015-12-02 08:56:02 +0100 (CET)