Verwenden wir in Skripten lange Optionen

 (matklad.github.io)
6 Punkte von GN⁺ 2025-03-23 | 1 Kommentare | Auf WhatsApp teilen
  • Viele Kommandozeilen-Utilities unterstützen kurze Optionen (-f) und lange Optionen (--force)
  • Die kurze Form ist für die interaktive Nutzung gedacht; in Skripten wird empfohlen, die lange Form zu verwenden
  • Zum Beispiel gibt man im Terminal $ git switch -c my-new-branch ein.
  • In Release-Skripten schreibt man es so:
    • try shell.exec("git fetch origin --quiet", .{});
    • try shell.exec("git switch --create release-{today} origin/main", .{ .today = stdx.DateUTC.now() }, );
  • Lange Optionen sind für Leserinnen und Leser deutlich aussagekräftiger

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-23
Hacker-News-Kommentare

  • Ich bevorzuge lange Optionen, aber wenn man POSIX-Befehle portabel aufrufen muss, sind kurze Optionen die einzige Wahl. POSIX legt keine langen Optionen fest.

    • Zum Beispiel kann man die Spezifikation von diff heranziehen.
    • In den meisten Fällen ist es eine bessere Alternative, Library-Bindings zu verwenden, statt sich auf POSIX-Utilities zu verlassen.
    • Statt grep aufzurufen, kann es effizienter sein, etwas wie libpcre zu verwenden.
    • Bei Nicht-POSIX-Utilities wie git, hg, rg, ag usw. ist die Verwendung langer Optionen sinnvoll.

  • Man sollte String-Interpolation und Befehlsausführung nicht vermischen.

    • Besonders vorsichtig sollte man sein, wenn der Befehl über die Shell verarbeitet wird.
    • In jeder Sprache sollte man eine listen- oder arraybasierte Ausführungs-API verwenden, um Argumente direkt an execv(2), execvp(2) usw. zu übergeben.

  • Ich stimme zu, dass man lange Optionen verwenden sollte, aber man muss die Portabilität berücksichtigen.

    • Nicht alle BSD-Distributionen unterstützen lange Optionen im GNU-Stil.
    • Wenn man Portabilität möchte, sollte man kurze Optionen verwenden.

  • Man darf nicht vergessen, nach allen Optionen und vor dynamischen Argumenten -- zu verwenden.

  • Bevor man einen Befehl aufruft, sollte man prüfen, ob seine Länge größer als ARG_MAX ist.

    • Zum Beispiel bei folgendem Befehl:
      • grep --ignore-case --files-with-matches -- "hello" *.c
    • Sollte man ihn so aufrufen:
      • CMD="grep --ignore-case --files-with-matches -- \"hello\" *.c"
      • ARG_MAX=$(getconf ARG_MAX)
      • CMD_LEN=${#CMD}
      • if (( CMD_LEN > ARG_MAX )); then
      • echo "Error: Command length ($CMD_LEN) exceeds ARG_MAX ($ARG_MAX)." >&2
      • exit 1
      • fi
      • eval "$CMD" # Warnung: Dateinamen werden ausgewertet

  • Ich stimme diesem Ansatz zu. Ein weiterer Vorteil ist, dass sich in der Manpage leichter nachsehen lässt, was eine Option macht.

  • Wenn man ein Skript auf andere POSIX-Systeme portierbar machen will, muss man möglicherweise kurze Optionen verwenden.

    • Lange Optionen sind nicht standardisiert.
    • Man muss den Trade-off selbst abwägen.

  • Optionen sollte man in separate Zeilen setzen, damit sie leichter nachverfolgbar sind und git blame einfacher wird.

  • Das ist eine der Grundregeln beim Schreiben von Skripten. Wenn lange Optionen möglich sind, sollte man sie verwenden.

    • Das ist einfach zu vernünftig.

  • Optionen in Langform sind für Leser deutlich selbsterklärender.

    • Tippfehler passieren seltener.