Style d'options de ligne de commande - POSIX ou quoi?

Quelque part, j'ai vu une diatribe contre java / javac utilisant prétendument un mélange de Windows et de style Unix comme

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

À mon humble avis, ce n'est pas un mélange, c'est comme des findœuvres, n'est-ce pas? AFAIK, selon POSIX, la syntaxe devrait être comme

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

et -abcdefsignifierait spécifier 6 options courtes à la fois. Je me demande quelle version conduit en général à moins de frappe et moins d'erreurs.

J'écris un petit utilitaire en Java et en aucun cas je ne vais utiliser le style Windows /a /bcar je m'intéresse principalement à Unix. Quel style dois-je choisir?

Vous pouvez trouver les conventions d'argument POSIX dans le chapitre Conventions utilitaires . Le style POSIX se compose d'options avec un seul tiret suivi d'une seule lettre indiquant l'option, la valeur de l'argument étant séparée de l'option par un espace.

Il y a des exceptions aux règles - find, par exemple - mais elles sont dues aux précédents historiques Unix.

Le X Windows (X11) utilise des findoptions de noms longs similaires à un tiret unique.

Les options de nom long à double tiret ont été lancées par GNU (après un détour en utilisant +comme préfixe).

Voir cette question StackOverflow pour une discussion sur la grande variété de systèmes connus de gestion des arguments en ligne de commande - il y en a beaucoup. ( Comme cela a été écrit, je l' ai transféré les pouvoirs en être décidé la question SO 367309 n'a pas été un bon moyen pour SO. La réponse à une autre question, Quelle est la syntaxe générale d'une commande shell Unix? . )

Vous pouvez étendre la liste des techniques pour couvrir git(et un certain nombre d'autres systèmes) où vous obtenez une structure comme:

• basecommand[ options globales ] subcommand[ options de sous-commandes ] [nom ...]

Il peut y avoir de nombreuses sous-commandes, chacune avec son propre lexique d'options.

Bien sûr, Windows utilise la barre oblique (utilisée) ' /' pour indiquer les options au lieu du tiret ' -'.

JCL (pour z / OS et OS / 360 et les systèmes intermédiaires) a tendance à utiliser des paramètres de position séparés par des virgules et est généralement considéré comme non convivial ou une bonne interface.

EDIT: Il a été souligné que ce style est un GNU-isme, et que les Unix non basés sur GNU ont tendance à utiliser une syntaxe à tiret unique (en particulier, les variantes OS X et BSD).

Malgré son statut GNU-ism, de nombreux programmes de style Unix nouvellement écrits utilisent ce style:

• --long-option pour les noms d'options longs,
• -s pour les options courtes (un caractère),
• -abc pour plusieurs options courtes sans arguments (un caractère par option).
• Options avec arguments:
  • --long argou --long=argpour les options longues,
  • -s arg, -sargou (en option) -s=argpour les options courtes. Cela peut être combiné avec d'autres options courtes, tant que seule la dernière a un argument.
• La même option "sémantique" peut avoir plusieurs alias, le plus souvent un court (plus rapide à taper) et un long (plus facile à retenir).

Quiconque a utilisé un shell Linux pendant un certain temps doit être familier avec ce style ¹ , il a donc le principe de la moindre surprise de son côté. Permettre le regroupement de plusieurs options courtes sans être ambigu avec des options longues est également agréable.

¹ Par exemple, certains des programmes utilisant ce style (sur ma machine Linux): ls, grep, man, sed, bash, etc. ( EDIT: ce sont apparemment GNU-ismes cependant, les machines BSD et Mac OS X n'utilisent pas ce style)

Il y a plusieurs bibliothèques qui peuvent se charger d'analyser ceci pour vous (la plus connue étant l'implémentation GNU de getopt ), vous n'avez besoin que de spécifier quelles options longues et courtes existent, si elles prennent un argument, et que faire quand un est trouvée. (Et bien sûr, que faire pour les arguments positionnels, c'est-à-dire ceux qui ne commencent pas par -et qui ne sont pas des arguments des options précédentes)

findest un très ancien programme (ou peut-être plus probable: une version réécrite d'un très ancien programme) qui ne peut pas être facilement modifié pour utiliser une nouvelle syntaxe de ligne de commande. Trop de scripts se briseraient et trop d'utilisateurs habitués à l'ancienne syntaxe se plaindraient. javaca probablement été influencé par gccet amis, qui suivent également une ancienne syntaxe pour des raisons historiques.

• L'argument avec dash-dash ( --long-arg) est une convention GNU (voir leur implémentation getopt ).
• Les commandes POSIX n'utilisent jamais d'arguments à double tiret. Cela s'applique à la plupart des variantes d'Unix (Mac OS X, BSD) sauf Linux qui utilise GNU par défaut.

Pour votre projet Java, vous voudrez peut-être consulter GNU getopt pour Java ou Apache CLI . Ils soutiennent les deux conventions.

Une troisième option consiste à utiliser des arguments Java VM et à laisser le runtime les analyser pour vous:

 $ java -Dcolor=blue

Et puis, en code:

 System.getProperty("color");

Personnellement, j'utiliserais l' -Didiome et j'envelopperais l'incantation Java dans un script shell qui gère l'analyse en ligne de commande, y compris la vérification du chemin de classe, etc. Cela permet également aux utilisateurs natifs d'exécuter plus facilement votre programme Java.

Ça dépend. Personnellement, je préfère le style POSIX, mais dans votre cas, je viserais probablement la cohérence avec l'environnement dans lequel votre outil va être utilisé. Cela signifie utiliser la convention Java pour les fichiers JAR (sauf si vous prévoyez d'avoir un script wrapper qui le ferait ressembler à une commande Unix typique).