L'ordre des options de commande sous Linux est-il important?

Par exemple, lorsque je suis entré soit:

gcc -O hello.c -c

Ou

gcc hello.c -c -O

Les deux ne se sont pas plaints.

L'ordre des options de commande est-il important?

Cela dépend du programme lui-même; le système d'exploitation ne dicte pas si l'ordre est important ou non.

L'ensemble d'options de GCC est si colossal que je ne peux dire avec aucune autorité si vous pouvez fournir n'importe quelle option dans un ordre arbitraire; vous devrez lire la documentation de cette option. Cela dit, une règle générale est que si vous avez deux ou plusieurs options mutuellement exclusives (comme -O1 -O2pour différents niveaux d'optimisation), les programmes prendront généralement des options plus récentes que les précédentes. Encore une fois, cela n'est pas appliqué par Linux.

Un programme simple qui vous permet de spécifier la plupart des options dans n'importe quel ordre serait ls. La liste de tous les fichiers du répertoire actuel avec des détails peut être effectuée avec ls -la, ls -alou ls -l -a. Cependant, ls -l1 (c'est-à-dire 'el' 'one') ne donne pas la même sortie que ls -1l ('one' 'l'). Ce sont des options mutuellement exclusives, et la dernière répertoriée chevauche la première donnée.

Il y a aussi le programme étrange qui applique des options aux arguments lorsqu'ils arrivent. Ainsi, par exemple, vous pourriez avoir une commande hypothétique blah -a 1 2 -b 3où -as'applique aux trois arguments, mais -bne s'applique qu'à 3.

Encore une fois, cela dépend du programme individuel en question. En cas de doute, lisez la documentation.

Il y a des cas où l'ordre des options de ligne de commande est important même dans GCC. Si vous liez avec des bibliothèques statiques (.a), alors si vous spécifiez -llib1 -llib2et qu'il y a une fonction liblib2.aqui appelle une fonction liblib1.aqui n'a pas été introduite dans le programme, le lien échouera avec un symbole non résolu. Avec les bibliothèques partagées, ce n'est pas un problème.

En général, comme d'autres l'ont dit, l'ordre des options peut ou non faire une différence. Cependant, la sortie des deux commandes ci-dessous est différente - donc l'ordre des arguments pour catmodifier la sortie:

cat /etc/passwd /etc/group
cat /etc/group  /etc/passwd

Notez également que sous Linux (en particulier), GNU getopt()est apte à réorganiser la ligne de commande afin que toutes les options (commençant par un moins) soient traitées avant tout autre argument - sauf si vous utilisez un double tiret --pour marquer la fin de la ou à moins que vous ne définissiez la variable d'environnement POSIXLY_CORRECT.

Seulement si vous avez 2 options qui s'excluent mutuellement. Sinon, l'ordre n'a pas d'importance.

Bien sûr, cela peut varier selon la façon dont le programme a été écrit, mais devrait s'appliquer à tous les outils normaux * nix.

Difficile à savoir, comme d'autres vous l'ont déjà dit, cela peut faire une différence (ou pas).

Une bonne règle d'or consiste à ouvrir la page de manuel et à regarder le premier exemple et à utiliser cet ordre lorsque vous placez l'argument dedans.

Donc, si nous regardons la commande cat (man cat):

SYNOPSIS
       cat [OPTION] [FILE]...

Il semble que tant que toutes les options sont avant le fichier, vous devriez aller bien.

Et si nous regardons la bête gcc (man gcc):

SYNOPSIS
       gcc [-c|-S|-E] [-std=standard]
           [-g] [-pg] [-Olevel]
           [-Wwarn...] [-pedantic]
           [-Idir...] [-Ldir...]
           [-Dmacro[=defn]...] [-Umacro]
           [-foption...] [-mmachine-option...]
           [-o outfile] [@file] infile...

       Only the most useful options are listed here; see below for the remainder.  g++ accepts mostly
       the same options as gcc.

Ce n'est pas aussi simple à comprendre que la commande cat :)

Mais si vous souhaitez jouer en toute sécurité, -c semble venir avant -O, puis infile (hello.c) semble être le dernier.

gcc -c -O hello.c

Mais comme vous le savez déjà, puisque les autres fonctionnent ... cela joue très bien :)