Les tirets simples `--` pour les options à caractère unique, mais les tirets doubles` --` pour les mots?

D'où est venue la convention d'utiliser des tirets simples pour les lettres et des tirets doubles pour les mots et pourquoi continuer à être utilisé?

Par exemple, si je tape ls --help, vous voyez:

  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
      --author               with -l, print the author of each file
  -b, --escape               print octal escapes for nongraphic characters
      --block-size=SIZE      use SIZE-byte blocks
  -B, --ignore-backups       do not list implied entries ending with ~
...

J'ai essayé de googler - and -- conventionmême avec des citations avec peu de succès.

Dans l'art de la programmation Unix, Eric Steven Raymond décrit comment cette pratique a évolué:

Dans la tradition Unix d'origine, les options de ligne de commande sont des lettres uniques précédées d'un seul trait d'union ... Le style Unix d'origine a évolué sur des télétypes lents ASR-33 qui faisaient de la nuance une vertu; donc les options à lettre unique. Maintenir la touche Maj enfoncée nécessite un effort réel; par conséquent, la préférence pour les minuscules et l'utilisation de «-» (plutôt que du «+» peut-être plus logique) pour activer les options.

Le style GNU utilise des mots-clés d’option (plutôt que des lettres de mot-clé) précédés de deux traits d’union. Il a évolué des années plus tard, lorsque certains des utilitaires GNU plutôt élaborés ont commencé à manquer de clés d’option à une lettre ( c’est un correctif pour le symptôme, pas un traitement pour la maladie sous-jacente ). Il reste populaire car les options GNU sont plus faciles à lire que la soupe à l'alphabet des styles plus anciens. ¹

[1] http://www.faqs.org/docs/artu/ch10s05.html

Une des raisons pour continuer à utiliser les options à une seule lettre est qu’elles peuvent être combinées: ls -ltrc’est beaucoup plus facile à taper que ls --sort=time --reverse --format=long. Il existe un certain nombre de fois où les deux sont bons à utiliser. Pour ce qui est de rechercher ce sujet, essayez "convention des options de ligne de commande unix".

La citation de Raymond par @jasonwryan contient des informations utiles, mais commence au milieu de l'histoire:

• Gardez à l'esprit qu'Unix était à l'origine une version réduite de Multics et que tout au long de son histoire, les fonctionnalités d'Unix étaient souvent des imitations ou des adaptations de fonctionnalités vues et utilisées sur d'autres systèmes.
• Le '-'caractère d'option a été utilisé dans Multics. Bitsavers a un manuel pour ses commandes utilisateur .
• D'autres systèmes utilisaient des caractères différents, certains prétendant davantage être plus efficaces au clavier (tels que ceux '/'utilisés pour TOPS et VMS) et d'autres moins (comme ceux '('utilisés dans les CMS VM / SP).
• Les options Multics comportaient plusieurs caractères, par exemple des mots-clés séparés par un trait de soulignement.
• Les options Multics plus longues ont souvent une forme abrégée et abrégée, telle que -printvs -pr(page 3-8).
• Les options Unix étaient à caractère unique et, après plusieurs années, ont getoptété introduites. Comme il ne faisait pas partie de l’Unix original, il existe des utilitaires qui n’ont pas été utilisés getoptet qui sont restés tels quels . Mais avoir getoptaidé à rendre les programmes cohérents.

D'autre part, les options Unix utilisées getoptétaient à caractère unique. D'autres systèmes, en particulier les plus grands, ont utilisé des mots-clés. Certains (pas tous) ont autorisé l’ abréviation de ces mots-clés , c’est-à-dire que tous les caractères n'étaient pas fournis tant que l’option était sans ambiguïté. Ce test de l'ambiguïté présente des pièges. Par exemple:

• Au début de 1985, je travaillais sur un programme qui devait être porté sur PrimOS . Les développeurs de Prime ont concurrencé plusieurs autres entreprises en proposant un langage de commande imitant chacune d’elles, en fournissant les commandes les plus couramment utilisées. Bien sûr, ils ont soutenu les abréviations (tout comme VMS). Après avoir lu l'aide en ligne, j'ai tapé sta, pensant obtenir status. C'était l'abréviation de start, et n'ayant rien donné à commencer , l'interprète de commande m'a déconnecté.
• Le X Toolkit (utilisé par xterm ) permet des options abrégées. Pour utiliser cela efficacement dans xterm, il doit prétraiter les paramètres de commande de préférence -v(pour la version) par rapport à -vb(cloche visuelle). X Toolkit n’a aucun moyen direct de spécifier une option préférée en cas d’ambiguïté.

En raison de ce risque d'ambiguïté, certains développeurs préfèrent ne pas autoriser les abréviations. Lynx , par exemple, utilise des options multi-caractères sans autoriser les abréviations.

Tous les programmes ne sont pas utilisés getopt: taret psne l'ont pas été. Ni rcs(ou sccs) non plus, comme vous pouvez le constater en notant où le tiret était facultatif et les valeurs d’option facultatives.

Tenant compte de tout cela, les développeurs GNU ont adapté les options de mot-clé utilisées dans d’autres systèmes en getoptoffrant une version longue de chaque option courte. Par exemple, textutils 1.0 changelog dit

Tue May  8 03:41:42 1990  David J. MacKenzie  (djm at abyss)

        * tac.c: Use regular expressions as the record boundaries.
        Give better error messages.
        Reformat code and make it more readable.
        (main): Use getopt_long to parse options.

Le changement de fileutils était plus tôt:

Tue Oct 31 02:03:32 1989  David J. MacKenzie  (djm at spiff)

        * ls.c (decode_switches): Add long options, using getopt_long
        instead of getopt.

et quelqu'un peut en trouver un encore plus tôt, mais il semble que l'en-tête de fichier indique la date la plus proche:

/* Getopt for GNU.
   Copyright (C) 1987, 1989 Free Software Foundation, Inc.

qui est (par exemple) concurrente de X Toolkit (1987). La plupart des utilitaires Unix avec lesquels vous êtes habitués (tels que ls, ps) ont utilisé les options existantes à un caractère qui nécessitent des visites périodiques du manuel. Lors de l’introduction getopt_long, les développeurs GNU ne l’avaient pas fait en ajoutant d’ abord de nouvelles options; ils ont commencé par tabuler les options existantes et en fournissant une option longue correspondante.

Parce qu'ils ajoutaient à un répertoire existant, il y avait (encore une fois) le problème du conflit avec les options existantes. Pour éviter cela, ils ont modifié la syntaxe en utilisant deux tirets avant les options longues.

Ces programmes continuent à être utilisés getopt_longde cette manière pour les raisons habituelles:

• les scripts dépendent des options; les développeurs ne sont pas soucieux de casser les scripts
• il y a une norme de codage écrite (qui peut être efficace)
• personne n'a mis au point un ensemble d'outils concurrents qui est nettement incompatible (les développeurs BSD et GNU copient les noms d'options entre eux)

Dans l' interface de ligne de commande wikipedia , il est indiqué:

Dans les systèmes de type Unix, le trait d'union minuscule ASCII est généralement utilisé pour spécifier des options. Le caractère est généralement suivi d'une ou plusieurs lettres. Un argument qui ne comporte qu'un seul trait d'union, sans lettre, indique généralement qu'un programme doit gérer les données provenant de l'entrée standard ou envoyer des données à la sortie standard. Deux caractères moins un trait d'union (-) sont utilisés sur certains programmes pour spécifier des "options longues" dans lesquelles des noms d'options plus descriptifs sont utilisés. C'est une caractéristique commune du logiciel GNU.

Je suppose que plus d'options descriptives étaient souhaitées et qu'avec les options plus longues, vous n'aurez plus à vous soucier de manquer d'options à un seul personnage.

Une fois que vous avez décidé de vouloir des options longues, vous avez un problème, du moins si vous prévoyez de prendre en charge les options longues et courtes. Je ne suis pas positif, mais je pense que la réponse d’Arcege est la clé de la raison - et -. Une routine de traitement générique, par exemple. getopt_long (), aurait besoin de savoir si un seul argument en ligne de commande peut contenir plusieurs options, par exemple. -ltr. Ainsi, une routine de traitement devrait être capable de différencier les deux. Si je lis un seul tiret, -, le reste de l'argument de la ligne de commande peut correspondre à plusieurs options. Si je lis un double tiret, -, le reste de l'argument de la ligne de commande doit correspondre à une seule option.

Récemment, j'ai utilisé getopt_long () et je commence à aimer les longues options car elles sont plus faciles à mémoriser et à documenter. Si j'ai les deux commandes suivantes:

./aggregator -f 15

./aggregator --flush-time 15

Je dirais que le second en utilisant l'option longue est plus explicite.

Il y a probablement plusieurs raisons pour lesquelles les deux méthodes sont utilisées. La première est, bien sûr, la tradition. Les programmeurs et les utilisateurs sont des humains, et les humains s'attendent à ce que les choses fonctionnent d'une certaine manière. S'il n'y a aucune raison de changer (et vraiment, pour une ligne de commande, il n'y a pas beaucoup de raison de changer), alors ne le faites pas.

Cela étant dit, je sais qu'il existe des outils qui utilisent le trait d'union comme option longue ou même suppriment les traits d'union. Ces outils peuvent être difficiles au début et ont tendance à rester visibles dans un système autrement unifié.

Quand j’apprenais la différence entre les deux (et avant que cela devienne une seconde nature), je me souvenais toujours que le trait d’union "court" correspond aux options "court", tandis que le trait d'union "long" (ou double) correspond au "long" Les options. Je ne sais pas si ce raisonnement a été utilisé dans le développement du style à double trait d'union, mais c'est une possibilité.