Stile delle opzioni della riga di comando - POSIX o cosa?

Da qualche parte ho visto un rant contro java / javac presumibilmente usando un mix di Windows e Unix come

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

IMHO, non è un mix, è proprio come findfunziona, no? AFAIK, secondo POSIX, la sintassi dovrebbe essere simile

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

e -abcdefsignificherebbe specificare 6 opzioni brevi contemporaneamente. Mi chiedo quale versione porti in generale a meno digitazioni e meno errori.

Sto scrivendo una piccola utility in Java e in nessun caso userò lo stile di Windows /a /bpoiché mi interessa principalmente Unix. Quale stile dovrei scegliere?

È possibile trovare le convenzioni degli argomenti POSIX nel capitolo Convenzioni dell'utilità . Lo stile POSIX è costituito da opzioni con un singolo trattino seguito da una singola lettera che indica l'opzione, con il valore dell'argomento separato dall'opzione da uno spazio.

Esistono eccezioni alle regole find, ad esempio, ma a causa dei precedenti storici di Unix.

La X Windows (X11) utilizza findopzioni simili a trattino singolo, nome lungo.

Le opzioni di nome lungo a doppio trattino sono state introdotte da GNU (dopo una deviazione che utilizzava +come prefisso).

Vedi questa domanda StackOverflow per una discussione sull'ampia varietà di noti sistemi di gestione degli argomenti della riga di comando: ce ne sono molti. ( Dal momento che questo è stato scritto, il potere-che-essere decisa la questione SO 367309 non è stata una buona misura per SO. Ho trasferito la risposta a un'altra domanda, Qual è la sintassi generale di un comando Unix shell? . )

È possibile estendere l'elenco di tecniche per coprire git(e un numero di altri sistemi) in cui si ottiene una struttura come:

• basecommand[ opzioni globali ] subcommand[ opzioni sotto-comando ] [nome ...]

Ci possono essere molti sotto-comandi, ognuno con il proprio lessico di opzioni.

Ovviamente, Windows usa la barra ("usata") /per indicare le opzioni anziché il trattino " -".

JCL (per z / OS e OS / 360 e sistemi intermedi) tende a utilizzare parametri posizionali separati da virgole ed è generalmente considerato non intuitivo o di buona interfaccia.

EDIT: è stato sottolineato che questo stile è un GNU-ismo e che gli Unix non basati su GNU tendono ad usare una sintassi a trattino singolo (in particolare, varianti di OS X e BSD).

Nonostante sia lo stato di GNU-ism, molti programmi in stile Unix appena scritti usano questo stile:

• --long-option per nomi lunghi di opzioni,
• -s per opzioni brevi (di un carattere),
• -abc per più opzioni brevi senza argomenti (un carattere per opzione).
• Opzioni con argomenti:
  • --long argo --long=argper lunghe opzioni,
  • -s arg, -sargO (a scelta) -s=argper le opzioni brevi. Questo può essere combinato con altre opzioni brevi, purché solo l'ultimo abbia un argomento.
• La stessa opzione "semantica" può avere diversi alias, più comunemente uno corto (più veloce da digitare) e uno lungo (più facile da ricordare).

Chiunque abbia usato una shell Linux per un certo periodo di tempo dovrebbe avere familiarità con questo stile ¹ , quindi ha il principio della minima sorpresa dalla sua parte. È anche bello consentire il raggruppamento di più opzioni brevi senza essere ambigui con opzioni lunghe.

¹ Per esempio, alcuni dei programmi che utilizzano questo stile (sulla mia macchina Linux): ls, grep, man, sed, bash, ecc ( EDIT: queste sono apparentemente GNU-ismi però, macchine BSD e OS X non utilizzare questo stile)

Esistono diverse librerie che possono occuparsi di analizzare questo per te (la più nota è l'implementazione di getopt di GNU ), che richiede solo che tu specifichi quali opzioni lunghe e brevi esistono, se accettano un argomento e cosa fare quando un opzione trovata. (E ovviamente, cosa fare per gli argomenti posizionali, cioè quelli che non iniziano con -e non sono argomenti rispetto alle opzioni precedenti)

findè un programma molto vecchio (o forse più probabile: una versione riscritta di un programma molto vecchio) che non può essere facilmente modificato per utilizzare una nuova sintassi della riga di comando. Troppi script si spezzerebbero e troppi utenti abituati alla vecchia sintassi si lamenterebbero. javacè stato probabilmente influenzato da gcce amici, che allo stesso modo seguono una vecchia sintassi per motivi storici.

• L'argomento con dash-dash ( --long-arg) è una convenzione GNU (vedere la loro implementazione getopt ).
• I comandi POSIX non usano mai argomenti a doppio trattino. Questo vale per la maggior parte delle varianti di Unix (Mac OS X, BSD) ad eccezione di Linux che utilizza GNU per impostazione predefinita.

Per il tuo progetto Java, potresti voler dare un'occhiata a GNU getopt per Java o Apache CLI . Supportano entrambe le convenzioni.

Una terza opzione è quella di utilizzare gli argomenti Java VM e lasciare che il runtime li analizzi per te:

 $ java -Dcolor=blue

E poi, nel codice:

 System.getProperty("color");

Personalmente, userei il -Dlinguaggio e avvolgerei l'incantesimo Java in uno script di shell che gestisce l'analisi della riga di comando incluso il controllo del percorso di classe, ecc. Ciò semplifica anche l'esecuzione del programma Java per gli utenti nativi.

Dipende. Personalmente preferisco lo stile POSIX, ma nel tuo caso probabilmente mirerei alla coerenza con l'ambiente in cui verrà utilizzato il tuo strumento. Questo significa usare la convenzione Java per i JAR (a meno che non si preveda di avere uno script wrapper che lo faccia apparire come un tipico comando Unix).