Stil der Befehlszeilenoptionen - POSIX oder was?

Irgendwo habe ich einen Rant gegen Java / Javac gesehen, der angeblich eine Mischung aus Windows- und Unix-Stil verwendet

java -classpath ... -ea ... Something

IMHO, es ist keine Mischung, es ist genauso wie es findfunktioniert, nicht wahr? AFAIK zufolge sollte die Syntax POSIX-konform sein

java --classpath ... --ea ... Something

und -abcdefwürde bedeuten, 6 kurze Optionen auf einmal anzugeben. Ich frage mich, welche Version im Allgemeinen zu weniger Tipparbeit und weniger Fehlern führt.

Ich schreibe ein kleines Hilfsprogramm in Java und werde auf keinen Fall den Windows-Stil verwenden, /a /bda ich mich hauptsächlich für Unix interessiere. Welchen Stil soll ich wählen?

Sie finden die Konventionen für POSIX-Argumente im Kapitel Konventionen für Hilfsprogramme. Der POSIX-Stil besteht aus Optionen mit einem einzelnen Bindestrich, gefolgt von einem einzelnen Buchstaben, der die Option angibt, wobei der Argumentwert durch ein Leerzeichen von der Option getrennt ist.

Es gibt findzum Beispiel Ausnahmen von den Regeln , aber diese sind auf die historischen Unix-Präzedenzfälle zurückzuführen.

X Windows (X11) verwendet findähnliche Optionen für lange Namen mit einem Strich.

Die Double-Dash-Optionen für lange Namen wurden von GNU entwickelt (nach einem Umweg, der +als Präfix verwendet wurde).

In dieser StackOverflow- Frage finden Sie eine Diskussion über die Vielzahl der bekannten Kommandozeilen-Argumentbehandlungssysteme - es gibt viele. ( Da dies geschrieben wurde, die Befugnisse-that-werden , um die Frage SO beschlossen 367309 war nicht eine gute Passform für SO. Ich die Antwort auf eine andere Frage übertragen haben, was die allgemeine Syntax einer Unix - Shell - Befehl ist? . )

Sie können die Liste der Techniken erweitern, um git(und eine Reihe anderer Systeme) abzudecken, bei denen Sie eine Struktur erhalten wie:

• basecommand[ globale Optionen ] subcommand[ Unterbefehlsoptionen ] [Name ...]

Es kann viele Unterbefehle geben, von denen jeder ein eigenes Lexikon mit Optionen enthält.

Natürlich verwendet Windows einen (verwendeten) Schrägstrich " /", um Optionen anstelle des Bindestrichs " -" anzugeben .

JCL (für z / OS, OS / 360 und Zwischensysteme) verwendet in der Regel durch Kommas getrennte Positionsparameter und wird im Allgemeinen als nicht benutzerfreundlich oder als gute Schnittstelle angesehen.

EDIT: Es wurde darauf hingewiesen, dass dieser Stil ein GNU-ismus ist und dass Unixe, die nicht auf GNU basieren, in der Regel eine Single-Dash-Syntax verwenden (insbesondere OS X- und BSD-Varianten).

Trotz des GNU-Status verwenden viele neu geschriebene Programme im Unix-Stil diesen Stil:

• --long-option für lange Optionsnamen
• -s für kurze (Ein-Zeichen-) Optionen,
• -abc für mehrere kurze Optionen ohne Argumente (ein Zeichen pro Option).
• Optionen mit Argumenten:
  • --long argoder --long=argfür lange Optionen,
  • -s arg, -sargoder (optional) -s=argfür kurze Optionen. Dies kann mit anderen kurzen Optionen kombiniert werden, sofern nur die letzte ein Argument enthält.
• Dieselbe "semantische" Option kann mehrere Aliase haben, am häufigsten einen kurzen (schneller zu tippenden) und einen langen (leichter zu merkenden).

Jeder, der längere Zeit eine Linux-Shell verwendet hat, sollte mit diesem Stil ¹ vertraut sein , damit er das Prinzip der geringsten Überraschung auf seiner Seite hat. Es ist auch schön, die Gruppierung mehrerer kurzer Optionen zuzulassen, ohne mit langen Optionen mehrdeutig zu sein.

¹ Zum Beispiel einige der Programme mit diesem Stil (auf meinem Linux - Rechner): ls, grep, man, sed, bashusw. ( EDIT: diese sind offenbar GNU-isms obwohl, BSD und O X - Maschinen verwenden Sie diesen Stil nicht)

Es gibt mehrere Bibliotheken, die sich darum kümmern können, dies für Sie zu analysieren (die bekannteste ist die Implementierung von getopt durch GNU ). Sie müssen lediglich angeben, welche Long- und Short-Optionen vorhanden sind, ob sie ein Argument annehmen und was wann zu tun ist Option gefunden. (Und natürlich, was für Positionsargumente zu tun ist, dh solche, die nicht mit -früheren Optionen beginnen und keine Argumente für diese sind)

findist ein sehr altes Programm (oder wahrscheinlich eine neu geschriebene Version eines sehr alten Programms), das nicht einfach geändert werden kann, um eine neue Befehlszeilensyntax zu verwenden. Zu viele Skripte würden kaputt gehen und zu viele Benutzer, die an die alte Syntax gewöhnt sind, würden sich beschweren. javacwurde wahrscheinlich von gccund Freunden beeinflusst, die aus historischen Gründen ebenfalls einer alten Syntax folgen.

• Das Argument mit dash-dash ( --long-arg) ist eine GNU-Konvention (siehe deren getopt- Implementierung).
• POSIX-Befehle verwenden niemals doppelte Gedankenstriche. Dies gilt für die meisten Unix-Varianten (Mac OS X, BSD) mit Ausnahme von Linux, das standardmäßig GNU verwendet.

Für Ihr Java-Projekt sollten Sie GNU getopt für Java oder Apache CLI ausprobieren . Sie unterstützen beide Konventionen.

Eine dritte Möglichkeit besteht darin, Java VM-Argumente zu verwenden und sie von der Laufzeit für Sie analysieren zu lassen:

 $ java -Dcolor=blue

Und dann im Code:

 System.getProperty("color");

Persönlich würde ich das -DIdiom verwenden und die Java-Beschwörung in ein Shell-Skript einbinden, das das Kommandozeilen-Parsen einschließlich der Überprüfung des Klassenpfads usw. übernimmt. Dies macht es auch für native Benutzer einfacher, Ihr Java-Programm auszuführen.

Es hängt davon ab, ob. Ich persönlich bevorzuge den POSIX-Stil, aber in Ihrem Fall würde ich wahrscheinlich die Konsistenz mit der Umgebung anstreben, in der Ihr Tool verwendet werden soll. Dies bedeutet, dass Sie die Java-Konvention für JARs verwenden (es sei denn, Sie möchten ein Wrapper-Skript verwenden, das es wie einen typischen Unix-Befehl aussehen lässt).