Warum beginnen die Argumente von Konsolenanwendungen mit einem der folgenden Elemente:
a) one dash (myapp -arg1 123; ls -al)
b) two dashes (myapp --arg1 123; git push origin master --force)
c) without dashes at all (myapp 123; man ls)
d) without dashes but with the equal sign (myapp arg1=123; dd if=/dev/zero)
Gibt es da keine Standardkonvention? Selbst bei den Standard-Linux-Anwendungen kommen alle drei Fälle a), b) und d) gleichzeitig vor. Und es ist schwer, sich zu merken, wann ich beispielsweise -help und wann --help verwenden soll.
Antwort1
Striche kennzeichnenOptionen, die das Verhalten des Befehls ändern. Argumente ohne Bindestriche bezeichnen die Hauptparameter des Befehls, häufig sind dies Dateinamen.
Einzelne Bindestriche leiten normalerweise Optionen ein, die aus nur einem Buchstaben bestehen. Mehrere solcher Optionen können zusammengefasst und ls -a -lals abgekürzt werden ls -al. Dies war die Standardkonvention für die meisten frühen Unix-Befehle.
Doppelte Bindestriche leiten Optionen ein, die ganze Wörter sind. Diese Konvention ist notwendig, um sie von der oben beschriebenen Gruppierung zu unterscheiden. Dieser Optionsstil wurde durch die GNU-Versionen von Dienstprogrammen populär gemacht, da diese oft so viele Funktionen hatten, dass ihnen die mnemonischen Einzelbuchstaben ausgingen.
Manchmal erfordert eine Option einen eigenen Parameter. Die Stile hierfür variieren: Einige Befehle verwenden -o parameter, einige verwenden -oparameter, einige verwenden --option=parameterund einige erlauben mehrere Formen.
Es gibt auch eine Handvoll Befehle, die ihre eigenen, eigentümlichen Argumentationsstile erfunden haben. Dabei handelt es sich in der Regel um sehr alte Befehle, die aus der Zeit vor der Einführung eines Konsenses über Argumentationskonventionen stammen. Beispiele hierfür sind tarund dd. findist auch insofern ungewöhnlich, als dass es sich um einen alten Befehl handelt, der vor der Einführung der Konvention vollständige Wortoptionen verwendete --; seine Argumente sind praktisch eine eigene Sprache, da seine Anforderungen nicht in das typische command -options parametersParadigma passen.
Ein weiterer Grund für die Abweichungen zwischen den Befehlen ist, dass Unix ursprünglich keine Bibliotheksfunktion zur Argumentanalyse hatte. Erst später, als Unix bereits existierte, wurden die Funktionen getoptund getoptserstellt. Die Verwendung dieser Bibliotheken zwingt Sie im Wesentlichen dazu, gängigen Vorgehensweisen zu folgen. Ältere Programme führten jedoch ihre eigene Ad-hoc-Argumentanalyse durch, und verschiedene Programmierer trafen unterschiedliche Entscheidungen.
Antwort2
@Barmar hat Recht, aber es fehlen ein paar Informationen. Warum dies tatsächlich passiert, liegt ausschließlich daran, wie der Programmcode geschrieben wurde und genauer gesagt daran, was zum Parsen der Argumente verwendet wurde.
Bevor ich näher darauf eingehe, möchte ich einige Begriffe klären. Zunächst einmal sind die sogenannten „Optionen“ eigentlich auch Argumente. Tatsächlich ist alles, was Sie in die Befehlszeile eingeben, ein Argument (einschließlich des Programmnamens). Diese Argumente werden dann normalerweise in einem Array gespeichert ( argvin C so genannt). Dann entscheidet das Programm, wie (oder ob) diese Argumente analysiert werden und verhält sich entsprechend. Argumente haben normalerweise eine von drei Formen:
- Flags (nehmen kein Argument an; schalten einfach ein Verhalten ein oder aus)
- Schalter (nehmen ein Argument an; ändern das Verhalten basierend auf dem Argument)
- Parameter (einfache Daten, die nicht dazu bestimmt sind, das Verhalten zu ändern)
1und 2werden oft als bezeichnet OPTIONSund sollen das Programmverhalten ändern, aber beide kommen in unterschiedlichen Stilen vor (wie auch von Barmar erwähnt). Die getoptBibliothek von C bietet in diesem Bereich tatsächlich viel Flexibilität. Obwohl die Konvention darin besteht, Optionen entweder als Einzelbuchstabe mit einem vorangestellten Bindestrich oder als vollständiges Wort mit zwei vorangestellten Bindestrichen anzugeben, getopterlauben Programme, die mit geschrieben wurden, tatsächlich, dass Folgendes gleichwertig ist (vorausgesetzt, es wird als Index helpangegeben ):h
-h,--h,--help
Allerdings -helpist eigentlich nicht zulässig von getopt(wenn ein Tool also -helpfür sein Verwendungsflag verwendet, können Sie ziemlich sicher sein, dass es nicht mit der getoptBibliothek geschrieben wurde). Dies liegt daran, dass getoptein einzelner Bindestrich als Signal für eine Liste kombinierter Optionen interpretiert wird und daher -helpals interpretiert wird -h -e -l -p.
Wenn Optionen Argumente annehmen (konventionell „Optargs“ genannt), gibt es außerdem einige Möglichkeiten, diese anzugeben. Im Folgenden – vorausgesetzt, der Index für optist o,und das opterfordert ein Optarg¹ – sind alle ebenfalls gleichwertig:
-oParameter,-o Parameter,--opt=Parameter,--opt Parameter
Obwohl die getoptBibliothek mittlerweile ein weit verbreiteter Standard ist, tarverwenden viele Tools, die davor erstellt wurden (wie beispielsweise ), immer noch ihr eigenes Parsing-Setup. Deshalb tar -xjfist es gleichwertig mit tar xjf.
Kurz zusammengefasst: getoptgab es nicht immer, daher mussten Programmierer Argumente auf ihre eigene Weise analysieren. Neuere Tools verwenden es jedoch normalerweise, sodass ihr Verhalten vernünftig und vorhersehbar ist.
1 Es gibt eine nicht gut dokumentierte Möglichkeit, Optionen zu haben, die ein Optarg annehmen können, aber nichterfordern1. Optionale Optargs verursachen allerlei nervige Dinge und führen dazu, dass einige der gebräuchlicheren Möglichkeiten, Optionen anzugeben, ungültig sind (da sie mehrdeutig wären). Glücklicherweise sind Argumente, die ein optionales Argument annehmen, nicht allzu häufig.
Antwort3
Optionen beginnen mit Bindestrich, normalerweise ein Buchstabe, mehrere Optionen können angegeben werden
ls -l -h
or
ls -lh
Optionen beginnen mit zwei Bindestrichen, normalerweise Wörter, mehrere Optionen können nicht funktionieren
ls --list --human