Quelle est la différence entre un tiret et deux tirets pour les paramètres d'invite de commande?
Je me demandais pourquoi certains programmes ont besoin que leurs paramètres d'invite de commande aient deux tirets alors que certains (la plupart) n'en exigent qu'un tiret devant?
Par exemple, la plupart des programmes ressemblent à ceci: relaxer -dtd toc.xml toc_gr.xml toc_jp.xml
Alors que certains programmes ressemblent à ceci: xmllint --valid toc.xml --noout
Quelle est la raison pour laquelle certains nécessitent deux tirets au lieu d'un? N’est-il pas logique pour tout le monde de s'en tenir à un standard (c'est-à-dire un tiret unique suffira).
Il suffit de faire ls --help et de regarder les options; cela devrait être évident pour vous.
Cela n'a rien à voir avec les paramètres. De nombreuses options ont une forme abrégée et une forme longue, et beaucoup ont l’une et pas l’autre.
Et aussi, en ce qui concerne les paramètres, c’est tout simplement que dans la forme longue, quand ils prennent un paramètre, on dirait qu’il est toujours avec un égal. Mais évidemment, les plus courts peuvent prendre tout autant de paramètres mais ils n'utilisent pas un égal.
Voici un extrait de ls --help ( man ls donne des informations équivalentes). Notez que certains ont une forme longue sans forme courte (--author, --block-size), d’autres ont une forme courte sans une forme longue (-c, -f, -g) et que certains ont à la fois une forme longue et une forme courte (-A/--almost-all, -b/--escape).
-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 ~
-c with -lt: sort by, and show, ctime (time of last
modification of file status information)
with -l: show ctime and sort by name
otherwise: sort by ctime
-C list entries by columns
--color[=WHEN] control whether color is used to distinguish file
types. WHEN may be `never', `always', or `auto'
Il n'y a pas de norme répandue. Il y a une certaine cohérence, par exemple dans GNU programmes, mais vous devez vérifier la documentation de chaque programme.
Citant Wikipedia , c'est moi qui souligne:
Dans les systèmes de type Unix, , le trait d'union 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 est un trait d'union - moins par lui-même, sans aucune lettre, spécifie 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 programmes 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.
Les traits d'union indiquent généralement un argument prédéfini. Je pense que cela sert à les différencier, par exemple. noms de fichiers ou autres étiquettes que vous pourriez utiliser comme arguments. Ce n'est pas toujours le cas, cependant (voir ci-dessous).
Vous trouverez souvent le même argument disponible à la fois comme option courte et comme option longue, comme par exemple. dans ls .
Certains programmes utilisent un seul trait d'union pour les options à un caractère et deux traits d'union pour les options à plusieurs caractères, mais pas tous (une variable GNU find vient à l'esprit). Certains programmes ont des traits d'union optionnels ou les sautent complètement (tar ou BSD ps viennent à l'esprit).
Parfois, les options longues (--foo) nécessitent des arguments, alors que les options courtes (-f) ne le sont pas (ou du moins impliquent un argument par défaut spécifique).
Les options courtes (par exemple, cut -d ' ') peuvent avoir des arguments, tandis que les options longues (par exemple, ls --all) ne les ont pas nécessairement.
Pour définir un comportement particulier d'un programme, vous devez parfois utiliser une option courte, pour d'autres, vous devez utiliser une option longue et pour certains, vous avez le choix.
Sur une note connexe, certains programmes ne peuvent gérer aucun espace entre une option et son argument , tandis que d'autres ne le peuvent pas.
Comme je l’ai écrit au début, il n’existe aucun comportement ni norme commune. Souvent, vous pouvez suivre un comportement similaire à la même bibliothèque que celle utilisée pour l'analyse des arguments, mais vous ne voulez probablement pas lire les sources pour le découvrir.
Vous ne pouvez vraiment pas déduire la syntaxe d'argument d'un programme de celle d'un autre.
Si vous considérez également Windows, la situation empire: alors que les appels de ligne de commande Windows utilisent généralement /f (du moins la plupart du temps, des caractères uniques) pour les options, avec : comme séparateur entre les options et leur valeur (voir par exemple ici ); Les utilitaires multiplates-formes sont répandus (tels que ceux que vous avez mentionnés) et apportent la syntaxe de trait d'union plus courante pour les arguments, avec toutes les incohérences mentionnées ci-dessus.
Ceci est une convention venant de * nix. Un double trait d'union précède les options lorsqu'elles sont écrites en entier , tandis qu'un trait d'union précède les options lorsqu'elles le sont écrit sous forme abrégée . Par exemple, ls --all --l, peut être raccourci à ls -al. Comme on le voit, toutes les options n’ont pas leur équivalent lettre unique, bien que les plus utilisées en aient généralement.
Le fait que l'option prenne un argument ne fait pas vraiment la différence - il peut soit les accepter, soit ne pas les accepter, quelle que soit la manière dont vous entrez l'option.
Cela n'a pas vraiment d'importance lorsque vous les écrivez pour une utilisation ponctuelle, mais lorsque vous écrivez des commandes, par exemple dans des fichiers .alias, il est habituel d'utiliser le formulaire complet. Purement pour la facilité de lecture pour la prochaine personne.
ce sont des syntaxes UNIX conventionnelles,
un argument de programme prend un trait d'union ("-") suivi d'une seule lettre lorsqu'il s'agit d'une simple option (par exemple: - v ) et de deux trait d'union (" - ") lorsque l'option accepte des arguments (par exemple: - fichier toc.xml ou - fichier = toc.xml )
aucun impact sur la fonctionnalité du programme.
le tiret simple est implémenté par le getopt et est une fonction standard posix, tiret double dans getopt_long et est un standard gnu.
Traditionnellement, un seul tiret fournit une option à un seul caractère comme celle-ci:
-A ou -V etc. mais ne doit pas nécessairement être limité à cela. par exemple. -Wall for gcc active tous les avertissements du compilateur pour la commande du compilateur gcc.
les arguments à double tiret ont tendance à être plus bavards et prennent souvent un paramètre fourni tel que --max-count = NUM. Cependant, --version ne prend pas d'égal.
De manière générale, il n’existe pas de règles ni de normes définies concernant la manière dont les arguments de programme doivent être spécifiés, mais uniquement un ensemble de traditions. Toutefois, si les fonctions d’analyse de ligne de commande getopt et getopt_long sont utilisées, les paramètres doivent généralement respecter la norme car les fonctions de bibliothèque imposent une certaine manière de le faire.