Czy kolejność opcji poleceń w Linuksie ma znaczenie?


15

Na przykład, kiedy wpisałem:

gcc -O hello.c -c

Lub

gcc hello.c -c -O

Obaj nie narzekali.

Czy kolejność opcji poleceń ma znaczenie?

Odpowiedzi:


19

To zależy od samego programu; system operacyjny nie decyduje, czy zamówienie ma znaczenie.

Zestaw opcji GCC jest tak kolosalny, że nie mogę powiedzieć żadnej władzy, czy możesz podać dowolną opcję w dowolnej kolejności; musisz przeczytać dokumentację dotyczącą tej opcji. To powiedziawszy, ogólna ogólna zasada jest taka, że ​​jeśli masz dwie lub więcej wzajemnie wykluczających się opcji (np. -O1 -O2Dla różnych poziomów optymalizacji), programy zazwyczaj przyjmą późniejsze opcje niż wcześniejsze. Ponownie, nie jest to wymuszone przez Linux.

Byłby to prosty program, który pozwala określić większość opcji w dowolnej kolejności ls. Listowanie wszystkich plików w bieżącym katalogu ze szczegółami można wykonać za pomocą albo ls -la, ls -alalbo ls -l -a. Jednak ls-l1 (czyli „el” „one”) nie daje takiego samego wyniku, jak ls -1l („jeden” „l”). Są to wzajemnie wykluczające się opcje, a ostatnie wymienione powyżej jeżdżą na pierwszym podanym.

Istnieje również program nieparzysty, który stosuje opcje do argumentów po ich przybyciu. Na przykład możesz mieć hipotetyczne polecenie, blah -a 1 2 -b 3które -adotyczy wszystkich trzech argumentów, ale -bdotyczy tylko 3.

Ponownie, to zależy od danego programu. Jeśli nie masz pewności, przeczytaj dokumentację.


BTW, ls -al path/to/dirjest poprawny, ale ls path/to/dir -alnie jest. Tak więc ls, musisz umieścić swoje opcje przed (opcjonalnym) katalogiem, którego zawartość chcesz wyświetlić.
jvriesem

6

Są przypadki, w których kolejność opcji wiersza poleceń ma znaczenie nawet w GCC. Jeśli łączysz się z bibliotekami statycznymi (.a), to jeśli określisz -llib1 -llib2i istnieje funkcja, liblib2.aktóra wywołuje funkcję, liblib1.aktóra nie została wprowadzona do programu, wówczas połączenie zakończy się niepowodzeniem z nierozwiązanym symbolem. W przypadku bibliotek współdzielonych nie stanowi to problemu.

Ogólnie, jak powiedzieli inni, kolejność opcji może, ale nie musi, mieć znaczenie. Jednak dane wyjściowe z dwóch poniższych poleceń są różne - więc kolejność argumentów catzmieniających dane wyjściowe:

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

Zauważ również, że w Linuksie (w szczególności) GNU getopt()może zmienić kolejność wiersza poleceń, tak aby wszystkie opcje (zaczynające się od minus) były przetwarzane przed dowolnym innym argumentem - chyba że użyjesz podwójnego myślnika --do oznaczenia końca argumenty lub chyba, że ​​ustawisz zmienną środowiskową POSIXLY_CORRECT.


4

Tylko jeśli masz 2 opcje, które wzajemnie się wykluczają. W przeciwnym razie kolejność nie ma znaczenia.

Oczywiście może się to różnić w zależności od tego, jak program został napisany, ale powinno mieć zastosowanie do wszystkich normalnych narzędzi * nix.


3

Trudno to wiedzieć, jak już inni mówili, może to mieć znaczenie (lub nie).

Dobrą zasadą jest otwarcie strony podręcznika i spojrzenie na pierwszy przykład i użycie tej kolejności przy wstawianiu arg.

Więc jeśli spojrzymy na polecenie kota (człowiek kot):

SYNOPSIS
       cat [OPTION] [FILE]...

Wygląda na to, że dopóki wszystkie opcje są przed argumentem pliku, powinieneś być w porządku.

A jeśli spojrzymy na bestię 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.

Nie jest to tak proste, jak polecenie kota :)

Ale jeśli chcesz grać bezpiecznie, wydaje się, że -c pojawia się przed -O, a następnie infile (hello.c) jest ostatnim.

gcc -c -O hello.c

Ale jak już wiesz, skoro inni pracują ... gra się bardzo bezpiecznie :)


A co z łączeniem flag -static-libstdc++?
Royi,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.