Styl opcji wiersza poleceń - POSIX czy co?

Gdzieś widziałem rant przeciwko java / javac rzekomo przy użyciu mieszanki stylów Windows i Unix

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

IMHO, to nie jest miks, to po prostu finddziała, prawda? AFAIK, zgodnie z POSIX, składnia powinna być podobna

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

i -abcdefoznaczałoby określenie 6 krótkich opcji jednocześnie. Zastanawiam się, która wersja ogólnie prowadzi do mniejszego pisania i mniej błędów.

Piszę małe narzędzie w Javie i w żadnym wypadku nie będę używać stylu Windows, /a /bponieważ interesuje mnie przede wszystkim Unix. Jaki styl powinienem wybrać?

Konwencje argumentów POSIX można znaleźć w rozdziale Konwencje narzędzi . Styl POSIX składa się z opcji z pojedynczym myślnikiem, po którym następuje pojedyncza litera oznaczająca opcję, z wartością argumentu oddzieloną od opcji spacją.

Istnieją wyjątki od reguł - findna przykład - ale są one spowodowane historycznymi precedensami uniksowymi.

X Windows (X11) używa findopcji długich nazw podobnych do pojedynczego myślnika.

Opcje długiej nazwy z podwójnym myślnikiem zostały zapoczątkowane przez GNU (po objeździe +jako prefiksu).

Zobacz to pytanie StackOverflow w celu omówienia szerokiej gamy znanych systemów obsługi argumentów wiersza poleceń - jest ich wiele. ( Ponieważ to było napisane, władzą, decyduje pytanie SO 367309 nie był dobrym rozwiązaniem dla tak. Mam przeniesiona odpowiedź na inne pytanie, co jest ogólna składnia polecenia Unix shell? . )

Możesz rozszerzyć listę technik, aby objąć git(i wiele innych systemów), w których otrzymujesz strukturę taką jak:

• basecommand[ opcje globalne ] subcommand[ opcje podrzędnych poleceń ] [nazwa ...]

Może istnieć wiele komend podrzędnych, z których każda ma własny słownik opcji.

Oczywiście system Windows używa (używanego) ukośnika „ /”, aby wskazać opcje zamiast myślnika -”.

JCL (dla systemów z / OS i OS / 360 oraz systemów pośrednich) zwykle używa parametrów pozycyjnych oddzielonych przecinkami i jest ogólnie uważany za nieprzyjazny dla użytkownika lub dobry interfejs.

EDYCJA: Wskazano, że ten styl jest GNU-izmem i że Uniksy oparte na GNU zwykle używają składni pojedynczego myślnika (w szczególności wariantów OS X i BSD).

Pomimo statusu GNU-ism, wiele nowo napisanych programów w stylu uniksowym używa tego stylu:

• --long-option dla długich nazw opcji,
• -s dla krótkich (jednoznakowych) opcji,
• -abc dla wielu krótkich opcji bez argumentów (jeden znak na opcję).
• Opcje z argumentami:
  • --long arglub --long=argdla długich opcji,
  • -s arg, -sargI (opcjonalnie) -s=argdo krótkich opcji. Można to połączyć z innymi krótkimi opcjami, o ile tylko ostatnia ma argument.
• Ta sama opcja „semantyczna” może mieć kilka aliasów, najczęściej krótką (szybszą do pisania) i długą (łatwiejszą do zapamiętania).

Każdy, kto używał powłoki Linuksa przez dłuższy czas, powinien znać ten styl ¹ , więc ma on zasadę najmniejszego zaskoczenia po swojej stronie. Przyjemne jest również grupowanie wielu krótkich opcji bez dwuznaczności przy długich opcjach.

¹ Na przykład, niektóre z programów wykorzystujących ten styl (na moim komputerze Linux): ls, grep, man, sed, bash, itd. ( EDIT: są to widocznie gnu-izmy choć maszyny BSD i OS X nie używają tego stylu)

Istnieje kilka bibliotek, które mogą zająć parsowania to dla ciebie (najbardziej znany jest realizacja GNU z getopt ), tylko potrzebuje was, aby określić co długie i krótkie opcje istnieją, czy biorą argument, i co zrobić, gdy opcja jest znaleziona. (I, oczywiście, co zrobić z argumentami pozycyjnymi, tj. Takimi, które nie zaczynają się od -i nie są argumentami dla poprzednich opcji)

findto bardzo stary program (a może bardziej prawdopodobne: przerobiona wersja bardzo starego programu), którego nie można łatwo zmienić w celu użycia nowej składni wiersza poleceń. Zepsuje się zbyt wiele skryptów, a zbyt wielu użytkowników przyzwyczajonych do starej składni narzeka. javacbył prawdopodobnie pod wpływem gccprzyjaciół i znajomych, którzy również stosują starą składnię z powodów historycznych.

• Argument z dash-dash ( --long-arg) jest konwencją GNU (zobacz ich implementację getopt ).
• Polecenia POSIX nigdy nie używają argumentów podwójnego myślnika. Dotyczy to większości wariantów Uniksa (Mac OS X, BSD) z wyjątkiem Linuksa, który domyślnie korzysta z GNU.

W przypadku projektu Java warto sprawdzić GNU getopt for Java lub Apache CLI . Wspierają obie konwencje.

Trzecią opcją jest użycie argumentów Java VM i pozwolenie, aby środowisko wykonawcze je przeanalizowało:

 $ java -Dcolor=blue

A następnie w kodzie:

 System.getProperty("color");

Osobiście -Dużywałbym tego idiomu i zawijałem inkantację Java w skrypcie powłoki, który obsługuje parsowanie wiersza poleceń, w tym sprawdzanie ścieżki klasy itp. Ułatwia to również rodzimym użytkownikom uruchamianie programu Java.

To zależy. Ja osobiście wolę styl POSIX, ale w twoim przypadku prawdopodobnie dążyłbym do spójności ze środowiskiem, w którym twoje narzędzie będzie używane. Oznacza to stosowanie konwencji JAR dla plików JAR (chyba że planujesz mieć skrypt otoki, który wyglądałby jak typowa komenda uniksowa).