Sollte ein CLI Tool die Hilfe ausgeben wenn man es ohne Argumente auführt, oder was sinnvolles tun?
Oder sollte es sogar einfach einen Fehler ausgeben?
Ich denke mal da wird man ne Meinung zu haben wenn man öfter CLI Programme nutzt, auch wenn das natürlich eher etwas ist wo man wenig drüber nachdenkt.
Um noch mal Beispiele zu nennen was so passieren kann:
pacman(package manager for arch) sagt dir "error: no operation specified (Use -h for help)"
yay(AUR helper) führt automatisch ein update durch(-Syu)
apt zeigt die Hilfe an
git zeigt die Hilfe an
ping sagt "usage Error, Destination address required"
man sagt "What manual do you want? For example, try 'man man'."
Gibt also sehr unterschiedliche ansätze, was findet ihr am besten? Klar, kommt auch aufs Programm an, aber pacman könnte ja nun auch ein Update machen, oder git könnte den Status anzeigen, etc...
Das Ergebnis basiert auf 7 Abstimmungen
5 Antworten
Das kommt auf das Programm an. Es gibt auch Commandline Tools welche einfach eine bestimmte Funktion ausführen wenn sie keine Argumente erhalten.
Es ist also eher die Frage ob es eine sinnvolle Operation gibt welche das Programm ausführen soll/kann wenn es ohne Argumente ausgeführt wird. Natürlich sollte der Programmname die Funktion des Programms beschreiben und es sollte mehr oder minder klar sein, was gemacht wird wenn man kein Argument angibt.
Wenn es keine sinnvolle Funktion gibt die das Programm ohne Argumente ausführen kann dann sollte es die Hilfe ausgeben oder eine Kurzversion der Hilfe.
Du kannst es so definieren.
Ob es sinnvoll ist oder nicht ist wieder etwas anderes. Git und Apt sind eher Interfaces da ist es einfach klarer die Funktion über ein Zusatzargument zu wählen.
Wie git status, git pull, git push, apt update, apt upgrade usw. sonst kann es sein dass der Verwender eine Funktion ausführt welche er nicht ausführen möchte. Der Aufruf ohne Argumente sollte zudem möglichst keine Änderungen am System vornehmen wobei das eben auch vom Programm abhängt.
Bei den Programmen make oder ls ist es hingegen vollkommen klar was es ohne Argument macht weil es schon mehr oder minder aus dem Programmnamen hervor geht.
"sonst kann es sein dass der Verwender eine Funktion ausführt welche er nicht ausführen möchte"
Nun, bei git status passiert ja nichts, das ändert nichts am system.
Und wenn ein apt update was am system ändert, wirst du ja nochmal extra nach einer Bestätigung gefragt. Yay macht das so, updated und upgraded automatisch wenn du es ohne Argumente ausführst. Und da beschwert sich eigentlich nicht wirklich jemand.
Wie gesagt du darfst es so definieren und es hält dich niemand davon ab.
Du hast nach einer Meinung gefragt und ich hab dir meine Meinung gegeben.
Apt und git sehe ich als Interfaceprogramme welche eine Reihe unterschiedlicher Funktionen ausführen können, da kann man sich eben schwer vorstellen was das ohne Argumente macht.
Beschweren würd ich mich darüber auch nicht ich würds nur nicht so machen.
Ein Programm ohne Argumente aufzurufen ist die kürzeste und einfachste Form des Aufrufs. Diese Aufrufmöglichkeit sollte nicht verschwendet werden.
Generell Hilfe oder Instruktionen anzuzeigen wäre eine solche Verschwendung, denn jeglicher Aufruf mit Funktion würde zusätzliche Argumente erfordern.
Das Programm sollte zu Ausführung seiner plausibelsten Aktion übergehen.
Das hängt extrem vom Zweck des Tools ab.
Das 'ls' ohne Parameter das aktuelle Verzeichnis listet ist naheliegend.
Das 'cp' ohne Parameter nichts sinnvolles machen kann ist auch irgendwie klar, also Fehlermeldung.
Eine Standardaktion sollte die vermutlich wahrscheinlichste Nutzerintention repräsentieren, aber nie ungefragt Änderungen irgend einer Form durchführen.
Nachtrag: Einfach die Hilfe auskübeln halte ich für eine schlechte Option - Nimm mal rsync, 180 Zeilen Hilfe udn ganz am Ende noch ne Fehlermeldung. Man könnte eine Usage ausgeben, sofern die Zahl der Optionen überschaubar ist.
Hallo
Wenn keine Argumente an ein Programm bzw. Shell Befehl übergeben werden, dann sollte das Programm möglichst das machen, wozu es da ist und nur einen Fehler melden, wenn ein Argument notwendig ist. Warum sollte ein Shell bzw. CLI Befehl prinzipiell die Hilfe anzeigen, wenn es ohne Argumente aufgerufen wird? Jede Menge Befehle benötige gar keine Argumente für die Ausführung.
mfG computertom
Ist de facto Standard... Sinnvoll ganz nebenbei auch ^^
Ich würde sagen eher --help ist standard, das hat fast jedes tool.
Bei manchen tools (wie ping) steht --help nichtmal in der hilfe selbst, weil das selbstverständlich ist.
Wenn das der standard ist, warum tun dass dann die meisten gnu tools die auf jedem linux rechner installiert sind, wie ping, cp, ls, dir, chmod... alle nicht?
Wo hast du diese standards her?
Ich bin mir relativ sicher, dass so ziemlich alle Kommandozeilentools bei ungültiger Eingabe von Argumenten (was eben in manchen Fällen keinen Argumenten entspricht) eine Meldung ähnlich "-h" for help oder bei größerem Umfang der Funktionalitäten eine Übersicht über die einzelnen Bereiche des Programms, docker zb...
Nein, die sagen dir alle mehr oder weniger nur "Fehler, falsches argument, rufe die hilfe mit --help auf"
(Die man, wenn man keine ahnung hat, auch direkt von anfang an mit --help aufrufen hätte können, weil quasi jedes programm was existiert --help hat)
Und, was ungültig ist, definiert doch der Entwickler. Wenn ich es in apt so definiere dass es ohne Argumente ein Update durchführt, dann ist das das nicht mehr ungültig. Das ist technisch ja garkein problem.
In der Regel keine gute Idee.
Programme sollten in der Regel nach dem sie stable sind(also 1.0.0 aufwärts) die Kompatibilität nicht kaputtmachen.
Solche Entscheidungen muss man ganz am Anfang treffen.
Dann verstehe ich den Sinn deiner Umfrage bzw. des dahinterstehenden Bestrebens nicht oder willst du dich einfach nur darüber aufregen, dass andere Menschen andere Vorstellungen haben als du?
Du brichst keine Abwärts-Kompatibilität bei Programmen, die statt eines Fehlers eine Hilfe anzeigen. Der Rückgabewert kann ja trotzdem ein Fehlercode sein.
Und abgesehen davon kann man auch Kompatibilität gerne brechen, wenn es sinnvoll ist.
Und es gibt genügend Programme, bei denen kein Argument notwendig ist. Bei diesen ist es eh hinfällig.
"Du brichst keine Abwärts-Kompatibilität bei Programmen, die statt eines Fehlers eine Hilfe anzeigen."
Andersrum aber schon.
Es geht mir vorallem um Programme wo beides denkbar ist, nichts zu tun, oder etwas zu tun.
Es kommt, natürlich, sich die Programm an. Aber die Frage ist halt was besser ist wenn beides möglich ist.
Und übrigens, vieles ist einheitlich.
Ich kenne jetzt z.B. kein etabliertes Programm dass kein --help hat.
Da gibt's den Grundsatz "no news, good news" - etwa "keine unnötigen Mitteilungen, wenn diese nicht erforderlich sind". Oder auch "mach bloss worum gefragt wurde, und gebe das aus, worauf sich die Anfrage bezieht". Also auch "help wenn darum gefragt wird" und nicht "immer dann, wenn einem nix anderes einfällt" - und help ist unabhängig von Hinweis "so wie eingegeben kann das nicht funktionieren"
So wie beim Eintippen von z.B. "ls" du erstmal drauf hingewiesen wirst, doch bitteschön erst ein Argument dranzuhängen, bevor dir eine Liste von Dateien angezeigt wird?
Bei ls ists ja auch recht eindeutig, bei rm würds hingegen keinen Sinn machen.
Ist meiner Meinung nach immer eine Frage des Programms und ob man sich unter dem "default Verhalten" etwas vorstellen kann bzw ob ein default sinnvoll ist.
auch bei rm braucht dann nicht gleich die man page gezeigt zu werden. Einfacher Hinweis das der Aufruf so wie ausgeführt nicht richtig ist reicht, eventuell mit Hinweis darauf, wo der Fehler liegt. Also z.B. "benötigt Argumente". Das ist ja auch was passiert.
Naja, git könnte z.B. "git status" ausführen ohne argumente, wäre durchaus eine sinnvolle funktion, git status wird sowieso quasi nie mit weiteren argumenten benutzt.
apt könnte "apt update" ausführen.
Die wenigste Software kann wirklich garnichts sinnvolles ohne Argumente(natürlich gibt es durchaus auch tools wie cp, wo man sich da nichts wirklich sinnvolles überlegen kann)