CommandLineParser

    • Offizieller Beitrag

    Angeregt durch die Kommandozeilenbehandlung in Nim habe ich das dortige "parseopt" Modul als Vorlage für eine ähnliche Umsetzung in AutoIt genutzt.

    Das ist nicht interessant für 2...3 Parameter in der Kommandozeile. Wer aber reine CUI-Anwendungen erstellt, wird u.U. eine Vielzahl möglicher Parameter bereitstellen wollen. Und da ist die in Nim genutzte Variante recht elegant und vielfältig. Für eine angenehmere Syntax habe ich Strukturen verwendet.

    Für die Funktion _CmdLineParser_Next() habe ich einen Iterator implementiert, sodass bei jedem Aufruf der Folgeparameter ausgegeben wird. Nach Erreichen des letzten Parameters wird beim Folgeaufruf $CMDLINEPARSE_END zurückgegeben.

    Ein Aufruf könnte z.B. so aussehen:

    c:\Pfad\meine.exe -f -b -c:7 --file="path to file\file.ext" argX argY

    Mi diesem Bsp. werden die gesamte Parameterzeile sowie die Informationen zu jedem Parameter ausgegeben:

    Übrigens, wenn ihr das aus SciTE heraus testet (mit Shift+F8 Parameter setzen) bekommt ihr 3 zusätzliche Parameter: /stdin /stdout "Programmaufrufzeile", die in kompilierten Skripten natürlich nicht enthalten sind.

    CommandLineParser
  • Übrigens, wenn ihr das aus SciTE heraus testet (mit Shift+F8 Parameter setzen) bekommt ihr 3 zusätzliche Parameter: /stdin /stdout "Programmaufrufzeile", die in kompilierten Skripten natürlich nicht enthalten sind.

    Ich bekomme nur 2 Parameter, /stdin fehlt bei mir.

    Wenn ich dein Bsp. in SciTE ohne zusätzliche Parameter starte, sollte die Ausgabe mit Index 1 enden, sie endet aber mit Index 4.

    Dies liegt daran, weil (bei mir) am Ende von $CmdLineRaw noch 4 Leerzeichen stehen, bzw. 3, wenn zusätzliche Parameter übergeben werden. Ist das bei dir nicht so?

    AutoIt
    ConsoleWrite("'" & $CmdLineRaw & "'" & @CRLF)
    ;==>> '/ErrorStdOut "F:\_Archive\_Programmieren\AutoIt3\User\BugFix\CmdLineParser\CmdLineParser_Example.au3"    '

    Deshalb habe ich die erste Zeile in der Funktion _CmdLineParser_Init so geändert, und alles ist wieder gut:

    AutoIt
    Local $cmdLine = StringStripWS($CmdLineRaw, 2)

    Fast alles...

    Zusätzliche Parameter: -file="test" --dir="m:\Temp" ; -file ist hier nicht korrekt, richtig wäre: --file

    Der Parameter -file wird einfach unterschlagen... hier sollte das Script mit einer Fehlermeldung (Usage) abbrechen.

    Zusätzliche Parameter: -file="test" --d="m:\Temp" ; --d ist hier nicht korrekt, richtig wäre: -d

    Hier sollte das Script auch mit einer Fehlermeldung abbrechen, da es sonst zu Konflikten mit -d kommen kann.

    key: /ErrorStdOut

    param: /ErrorStdOut

    Hm, in dem Fall hat key doch gar keinen Parameter?!

    Einmal editiert, zuletzt von Bitnugger (24. Mai 2020 um 09:06)

    • Offizieller Beitrag

    Wenn ich dein Bsp. in SciTE ohne zusätzliche Parameter starte, sollte die Ausgabe mit Index 1 enden, sie endet aber mit Index 4.


    Dies liegt daran, weil (bei mir) am Ende von $CmdLineRaw noch 4 Leerzeichen stehen, bzw. 3, wenn zusätzliche Parameter übergeben werden. Ist das bei dir nicht so?

    key: /ErrorStdOut

    param: /ErrorStdOut

    Hm, in dem Fall hat key doch gar keinen Parameter?!

    Das sind alles Fälle, die bei der Verwendung niemals auftreten, sondern ausschließlich in der Testumgebung mit SciTE. Insofern kann es getrost ignoriert werden.

    Zusätzliche Parameter: -file="test" --dir="m:\Temp" ; -file ist hier nicht korrekt, richtig wäre: --file

    Der Parameter -file wird einfach unterschlagen... hier sollte das Script mit einer Fehlermeldung (Usage) abbrechen.

    Ist so per Definition:

    Wird ein längerer Name übergeben, wird dieser ignoriert

    Fand ich sinnvoller, als das, was original in Nim damit passiert: "f", "i" und "l" würden dort als ShortNoVal erkannt werden, "e" wäre ShortVal mit val "test".

    Aber die Überlegung ist natürlich nicht verkehrt, den User über einen fehlerhaft übergebenen Parameter zu informieren. Muss ich mir mal Gedanken machen.

    Zusätzliche Parameter: -file="test" --d="m:\Temp" ; --d ist hier nicht korrekt, richtig wäre: -d

    Hier sollte das Script auch mit einer Fehlermeldung abbrechen, da es sonst zu Konflikten mit -d kommen kann.

    Auch hier ist das per Definition so, wobei ich hier das Verhalten aus Nim übernommen habe.

    Der Name hat eine Länge von mindestens 1 Zeichen

  • Das sind alles Fälle, die bei der Verwendung niemals auftreten, sondern ausschließlich in der Testumgebung mit SciTE. Insofern kann es getrost ignoriert werden.

    Die Leerzeichen am Ende des letzten Parameters können doch auch vorkommen, wenn eine Exe mit Parametern gestartet wird.

    Fand ich sinnvoller, als das, was original in Nim damit passiert: "f", "i" und "l" würden dort als ShortNoVal erkannt werden, "e" wäre ShortVal mit val "test".

    Ja, so kenne ich das auch von Linux her... den Parameter zu ignorieren, halte ich für keine gute Idee.

    PS: Einige Programme verwenden als Trennzeichen statt des "=" ein " ", z.B. http.exe -d C:/xampp/apache, oder gar keins, z.B. rar.exe -M5 -s.