Pourquoi les espaces entre les options et les parameters peuvent-ils être omis?

Lorsque vous écrivez le bit d'parsing de la command line de votre code, vous spécifiez les options qui prennent les arguments et celles qui ne le sont pas. Par exemple, dans un script shell acceptant une option -h (pour l'aide par exemple) et une option -a qui devrait prendre un argument, vous le faites

 opt_h=0 # default value opt_a="" while getopts 'a:h' opt; do case $opt in h) opt_h=1 ;; a) opt_a="$OPTARG" ;; esac done echo "h: $opt_h" echo "a: $opt_a" 

Le bit a a:h dit "J'attends d'parsingr deux options, -a et -h , et -a devrait prendre un argument" (c'est le : après a qui dit à l'parsingur que -a prend un argument).

Par conséquent, il n'y a jamais d'ambiguïté dans l'endroit où une option se termine, où sa valeur commence, et où un autre commence après cela.

Exécuter:

 $ bash test.sh -h -a hello h: 1 a: hello $ bash test.sh -h -ahello h: 1 a: hello $ bash test.sh -hahello h: 1 a: hello 

C'est pourquoi, la plupart du time, vous ne devez pas écrire votre propre parsingur de command line pour parsingr les options.

Il n'y a qu'un seul cas dans cet exemple qui est difficile. L'parsing s'arrête généralement à la première non-option, donc quand vous avez des trucs sur la command line qui ressemble à des options:

 $ bash test.sh -a hello -world test.sh: illegal option -- w test.sh: illegal option -- o test.sh: illegal option -- r test.sh: illegal option -- l test.sh: illegal option -- d h: 0 a: hello 

Ce qui suit résout que:

 $ bash test.sh -a hello -- -world h: 0 a: hello 

Le -- signale une fin des options de command line, et le bit -world est laissé pour que le programme fasse ce qu'il veut (c'est dans l'une des variables de position).

C'est, en passant, comment vous supprimez un file qui a un tiret au début de son nom de file avec rm .

EDIT :

Utilitaires écrits en C call getopt() (déclaré dans unistd.h ) qui fonctionne à peu près de la même façon. En fait, pour tout ce que nous soaps, la fonction bash getopts peut être implémentée en utilisant un appel à la fonction C getopt() . Perl, Python et d'autres langues ont des bibliothèques d'parsing de command line similaires, et il est très probable qu'elles effectuent leur parsing de la même manière.

Certaines de ces routines de bibliothèque getopt et getopt – getopt manipulent également des options "longues". Elles sont généralement précédées d'un double-tiret ( -- ), et les options longues qui prennent les arguments le font souvent après un signe égal, par exemple l' --block-size=SIZE de [certaines implémentations de] l'utilitaire du permet à -B SIZE de spécifier la même chose).

La raison pour laquelle les manuels sont souvent écrits pour montrer un espace entre les options courtes et leurs arguments est probablement pour la lisibilité.

EDIT : Les anciens outils, tels que les utilitaires dd et tar , ont des options sans tirets en face d'eux. Ceci est purement pour des raisons historiques et pour maintenir la compatibilité avec un logiciel qui repose sur eux pour fonctionner exactement de cette façon. L'utilitaire tar a acquis la possibilité de prendre des options avec des tirets plus récemment. Le manuel BSD pour tar appelle les anciennes options pour les "flags groupés".

xargs est l'un des utilitaires POSIX. POSIX documente le comportement d'parsing des options de la plupart de ses utilitaires pour faire correspondre getopt , avec quelques getopt pour d'autres implémentations, en disant dans 12.1 Syntaxe d'argument d'utilité :

Cette section décrit la syntaxe des arguments des utilitaires standard et introduit la terminologie utilisée dans POSIX.1-2008 pour décrire les arguments traités par les utilitaires.

Dans POSIX.1-2008, une notation spéciale est utilisée pour décrire la syntaxe des arguments d'un utilitaire. Sauf indication contraire , toutes les descriptions d'utilitaires utilisent cette notation, illustrée par cet exemple (voir Commandes simples XCU):

et concluant avec

Il est recommandé que tous les utilitaires et applications futurs utilisent ces directives pour améliorer la portabilité des users. Le fait que certains utilitaires historiques ne puissent pas être changés (pour éviter de briser les applications existantes) ne devrait pas dissuader ce futur objective.

Dans POSIX (callbackez-vous qu'il ne couvre que les utilitaires les plus couramment utilisés), il y a des exceptions qui passent des opérandes qui seraient des options dans d'autres utilitaires, soit des parameters de position , soit des parameters avec une syntaxe spéciale :

• dd – convertir et copyr un file
• expr – évalue les arguments comme une expression
• find le path [-H | -L] … [opérande_expression …]

POSIX autorise les options-valeurs facultatives :

Les arguments d'option sont présentés séparés de leurs options par des caractères <blank> , sauf lorsque l'option-argument est incluse dans la notation '[' et ']' pour indiquer qu'elle est facultative.

En revanche, je ne me souviens pas quels utilitaires POSIX utilisent cette fonctionnalité. Les utilitaires tic et infocmp ncurses utilisent la fonctionnalité pour les niveaux de l'option -v (verbose / debug).

Le point spécifique que vous avez demandé est détaillé dans le rest de ce paragraphe, sur plusieurs lignes.

Avant POSIX, certaines implémentations de ps acceptaient des options sans trait d'union. La description POSIX ne mentionne pas cela dans la description de l'utilitaire ou dans la syntaxe:

• ps – rapporter l'état du process

En dehors de POSIX, il existe des implémentations à option longue (comme GNU getopt_long ou X Toolkit ), en utilisant différentes methods pour séparer ou joindre la valeur d'une option à l'option. Par exemple, la ponctuation peut être utilisée:

 --option=value --option value 

En fonction de l'implémentation, un double-tiret peut / ne peut pas être utilisé pour distinguer les options longues de short (getopt): lynx et X Toolkit utilisent un seul tiret; GNU getopt_long utilise un double-tiret, par exemple. En outre, un + peut être utilisé pour indiquer qu'une option est annulée.

La description de POSIX ne semble pas en mentionner aucune, mais vous êtes certainement susceptible de les rencontrer.