Ist bei Befehlszeilenoptionen zwischen Optionsname und Wert ein Gleichheitszeichen erforderlich?

Ist bei Befehlszeilenoptionen zwischen Optionsname und Wert ein Gleichheitszeichen erforderlich?

Ich stelle nur kubectlals Beispiel fest:

kubectl run --image nginx ...

Und

kubectl run --image=nginx ...

beide arbeiten.

Gibt es für Kommandozeilenprogramme allgemein eine Regel, ob zwischen dem Optionsnamen und dem Wert ein Gleichheitszeichen erlaubt/erforderlich ist?

Antwort1

Im Allgemeinen bleibt die Implementierung der Interpretation von Befehlszeilenargumenten vollständig dem Ermessen des Programmierers überlassen.

Das gesagt,in vielen Fällen, der Wert einer „langen“ Option (wie sie beispielsweise mit eingeleitet wird --option_name) wird durch ein =zwischen dem Optionsnamen und dem Wert angegeben (also --option_name=value). Bei einstelligen Optionen ist es hingegen üblicher, Flag und Wert durch ein Leerzeichen zu trennen, wie beispielsweise -o value, oder gar keine Trennung zu verwenden (wie in -oValue).

Ein Beispiel aus der Manpage des GNU-Datumsdienstprogramms:

  -d, --date=STRING
        display time described by STRING, not 'now'
  -f, --file=DATEFILE
        like --date; once for each line of DATEFILE

Wie Sie sehen, würde der Wert bei der „Kurzform“ (also ) durch ein Leerzeichen vom Optionsschalter getrennt , bei der „Langform“ (also ) -djedoch durch ein .=--date

Bearbeiten

Wie Stephen Kitt betonte,GNU-Kodierungsstandardempfiehlt die Verwendung von getoptund getopt_longzum Parsen von Kommandozeilenoptionen. Die Manpage von getopt_longbesagt:

Eine lange Option kann einen Parameter der Form --arg=paramoder annehmen --arg param.

Ein Programm, das diese Funktion verwendet, akzeptiert also beide Formen.

Antwort2

Gibt es für Kommandozeilenprogramme allgemein eine Regel, ob zwischen Schalter und Wert ein Gleichheitszeichen erlaubt/erforderlich ist?

Nein, das gibt es nicht. Es gibt viele konkurrierende Standards in der Open-Source-Welt und in der Computerwelt allgemein (obligatorisches xkcd) und jeder kann jederzeit neue Regeln und Standards vorschlagen. Syntax der POSIX-Dienstprogrammargumente zum Beispiel erwähnt =überhaupt nicht zum Beispiel währendMann getopterwähnt es. In der Praxis kann man auf alle möglichen Kommandozeilenprogramme stoßen:

=Diejenigen, die nach oder nach einem Leerzeichen einen langen Optionswert annehmen :

$ touch a b c d
$ ls --format=verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d
$ ls --format verbose
total 0
-rw-r--r-- 1 ja users 0 Mar 17 14:39 a
-rw-r--r-- 1 ja users 0 Mar 17 14:39 b
-rw-r--r-- 1 ja users 0 Mar 17 14:39 c
-rw-r--r-- 1 ja users 0 Mar 17 14:39 d

Diejenigen, die keinen langen Optionswert benötigen =, aber ein Leerzeichen erfordern:

$ readelf  -a main | grep  'program interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ patchelf --set-interpreter=fake main
patchelf: getting info about '--set-interpreter=fake': No such file or directory
$ patchelf --set-interpreter fake main
$ readelf  -a main | grep  'program interpreter'
      [Requesting program interpreter: fake]

Diejenigen, die nach Wert annehmen =, aber keine Optionen mit -oder annehmen --:

dd if=/dev/urandom of=~/Desktop/test.txt bs=1M count=3

Es kann viele Gründe dafür geben, warum ein bestimmtes Kommandozeilenprogramm Eingaben auf eine bestimmte Art und Weise akzeptiert: die Vision des Autors, weil es niemanden interessiert, weil der Autor nicht wusste, dass jemand anders bereits einen Standard entwickelt hat, weil das Programm von einem anderen Betriebssystem mit völlig anderen Konventionen auf Unix portiert wurde oderwurde so gestaltet, als wäre es.

verwandte Informationen