...bevor ich im IRC oder im Forum einen Artikel verfasse dann schon. Es hängt natürlich von der Problemstellung ab. Manpages sind nicht das Allerheilmittel, aber sie helfen weiter.
3. Anlauf (manchmal auch "vorgezogen") Tante Google fragen; mit Stichwörtern die mein Verständnis-Problem ausmachen. Dabei kommt es auch vor, dass ich auf diesem Wege eine Manpage lese, die irgendwo auf einer Webseite steht. Zwei Vorteile dabei: scrollen und Ausschnitt wählen ist leichter, und zweitens von der Schrift her fällt mir das manchmal leichter, den (englischen) Text zu lesen, als im Terminal-Fenster.
Von Produktiv-Benutzer am Fr, 22. März 2019 um 15:50 #
Leider ist das enthaltene Wissen der Man-Pages nicht ohne Aufwand zu haben.
Leider sind oftmals Dokumentationen, die man sich online erarbeiten muss, deutlicher und hilfreicher.
Was also ist nicht "schick" an man-pages?
- Pager sind super, solange man Wochen an Erfahrung in der Bedienung eingebracht hat
- Sie folgen (obwohl Richtlinien vorhanden) keinem einheitlichen Stil.
- Viel zu wenig Beispiele in den einzelnen Pages
- "kurz mal reinschauen" bringt nur gut-geübten Benutzern den gewünschtein Erfolg zur gewünschten Zeit.
Zur eigentlichen Frage: Ja, gerne und sehr regelmässig.
Persönliches Fazit: Lokal verfügbare Dokumentation auf hohem Niveau ist sicher eine Schwachstelle der Benutzer-Erfahrung im Umgang mit Linux(als Betriebssystem nicht Kernel).
Von Produktiv-Benutzer am Fr, 22. März 2019 um 17:11 #
Ich dachte "User Experience" sei ein feststehender Begriff für alles, was den Nutzer und seine Erlebnisse beim Bedienen des System betrifft.
Wenn also Qualität der Dokumentation nicht gut, dann hat der Nutzer schlechte Erfahrung.
Zum Beispiel, weil er viel zu lange braucht, etwas zu finden und das schlicht, weil die Man-Page schlecht strukturiert ist und für Einsteiger tödlich: Keine Beispiele liefert.
Von kamome umidori am Sa, 23. März 2019 um 10:47 #
_Experience_ hat im Deutschen nicht nur eine Übesetzung – und je nach Fall ist eben nicht jede korrekt (https://dict.leo.org/englisch-deutsch/experience). Wenn auch viele falsch übersetzen, macht es das dennoch (noch) nicht richtig. In 100 Jahren ist das vermutlich völlig korrektes Deutsch – aber daran möchte ich dann bitte keine Mitschuld tragen ;) In der Sache hast Du natürlich recht – auch damit, dass Wortklauberei nichts zur Lösung beiträgt. Aber ich kriege regelmäßig die Krise, wenn ich _Benutzererfahrung_ oder _Expertise_ etc. „falsch“ verwendet sehe … Mein Problem … aber „Euer“ Fehler
Von Produktiv-Benutzer am So, 24. März 2019 um 08:05 #
Es liegt mir fern, durch Wortwahl Krisen zu verursachen. Sad Fact: In der Realität ist das oft der Fall. Die allermeisten Mitmenschen kümmern sich nicht um sprachliche Exaktheit. Damit meine ich nicht "von oben herab"-Sprech, sondern das Bewusstsein, dass man ständig Fehler macht, aber "auch mal nachschauen könnte", wenn dem mal wieder so war.
Damit sind wir beim von Dir angesprochenen Folge-Problem: "Nachschauen" und "viele verschiedene Möglichkeiten" führen nicht zum einen eindeutigen Ergebnis.
Ein generelles Problem mit den klassischen Unix-Handbuchseiten unter GNU/Linux ist, dass das GNU-Projekt primär ein anderes System zur Dokumentation seiner Software verwendet, nämlich GNU Info, und auch explizit erklärt, dass man pages unter GNU sekundär sind.[1]
Das heißt, wenn sich der Entwickler einer GNU-Software dazu entscheidet, keine klassische Handbuchseite mitzuliefern, gibt's die solange nicht, bis sie irgendwer anders schreibt. Das scheint auch ein gewichtiger Grund für das Fehlen von Beispielen in man pages unter GNU/Linux zu sein.
Allerdings hatte die Quasi-Ersetzung der man pages durch info pages unter GNU offenbar auch ein paar vernünftige Gründe und ist nicht der schiere Irrsinn, als der sie oft dargestellt wird.
Pager sind super, solange man Wochen an Erfahrung in der Bedienung eingebracht hat
Gut, dann hier zur allgemeinen Lebenszeitersparnis ein kleiner Spickzettel für less:
Zeilenweise scrollen: Cursor hoch/runter
Seitenweise scrollen: Bild auf/ab
Suche: / → Suchwort eingeben → Enter
Weitersuchen: N
Rückwärts suchen: Shift+N
Beenden: Q
Viel zu wenig Beispiele in den einzelnen Pages
Kannst du ein paar Handbuchseiten nennen, in denen das der Fall ist? Dann könnte man die mal mit dem vergleichen, was verschiedene BSD-Varianten und Solaris im jeweiligen Fall bieten.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Mär 2019 um 23:21.
Allerdings hatte die Quasi-Ersetzung der man pages durch info pages unter GNU offenbar auch ein paar vernünftige Gründe und ist nicht der schiere Irrsinn, als der sie oft dargestellt wird.
Der Irrsinn ist, dass das eigentliche GNU Tool, um diese GNU Info Seiten zu lesen, bei der Usability Jahre zurückliegt.
Was dazu führte, dass einige Entwickler alternative Clients dazu schrieben. Sinnvoller wäre es aber gewesen, den GNU Client auf Vordermann zu bringen.
Von Produktiv_Benutzer am Fr, 22. März 2019 um 20:08 #
Das info System hat nochmal eine eigene Benutzerschnittstelle. Das bedeutet wieder zusätzliche Lern-Arbeit, um an mehr Informationen zu kommen. Leider ist der gängige Weg, um sich das zu ersparen "raus aus dem System, rein ins Netz" (was natürlich zeitlich auch nicht eingegrenzt werden kann, wenn man die Suche startet).
Ein direktes Beispiel ist "man grep" (deutsche Seite, keine Beispiele).
Über man 1posix grep oder info grep kommt man natürlich zum Ziel. Aber der übliche Kommentar (ähnlich rtfm) ist ja "lies die Man-Page". "Na toll", denkt man sich lange Zeit.
Man page != Man Page und damit auch nicht eindeutig
Eine sehr wichtige Sache im täglichen Leben, auch wenn man irgendwelche Zeilen von anderen Leuten sieht, ist die Antwort auf "Was macht der Parameter denn?".
Dafür muss man halt konstruieren, sonst sucht man sich zu Tode. also "/^ +-c" z.B. für einen -c Parameter. Ist nicht Anfänger-Niveau, aber RegEx sind natürlich, sobald man sie kann, sehr nützlich.
Ich wusste nicht, wie man das Zitat schön formatieren kann, deswegen habe ich so getippt. Sorry dafür.
Allgemein find ich halt, dass genau die Dokumentation das Kernstück für die Akzeptanz beim Nutzer ist. Das manpage System war eine Offenbarung, als ich das erste Mal mit in Berührung kam. Aber im täglichen Leben gehört viel Frickelei dazu, innerhalb kurzer Zeit ein eindeutiges Resultat zu bekommen.
Viel schlimmer wird's ja, wenn Konzepte betroffen sind und nicht einzelne Parameter. Dann sucht man sich zu Tode, welche Auswirkungen LC_ALL z.B. auf was alles hat.
Benutzt wirklich jemand GNU Info? Hab schon mal davon gehört, es aber nie ernsthaft verwendet und auch alle Kollegen die unter Linux arbeiten lesen nur die Manpages. Ich habe nicht den Eindruck, dass die Manpages durch GNU Info ersetzt werden. Auch in WIkis oder in Foren wird meist nur auf die Manpages verwiesen.
Ich habe nicht den Eindruck, dass die Manpages durch GNU Info ersetzt werden.
Ich meinte damit lediglich den programmatischen Ansatz des GNU-Projekts, man pages als primäres Format der Systemdokumentation durch Texinfo-Seiten und einen entsprechenden Browser zu ersetzen, nicht die reale Situation unter GNU/Linux.
Das kann ich dir nicht beatworten. Ich nutze nur die klassischen Handbuchseiten und die Hilfetexte, die viele Programme per --help ausgeben, ansonsten WWW.
Der Standardbrowser für Texinfo-Seiten heißt info.
Im Übrigen wird nicht die man page bedient, sondern der Pager.
Von Produktiv-Benutzer am So, 24. März 2019 um 16:25 #
Sehr guter Tip. Die wesentlich verbesserte Navigation zu den Themen-Links (und damit eine Art Abstraktionsmöglichkeit) haben mich sofort verliebt werden lassen.
Wären hier nicht Bropages, Cheat, TLDRet al. eine Lösung, welche Beispiele für die unterschiedlichen Befehle auflisten? Natürlich sofern man keine Probleme mit der Installation weiterer Abhängigkeiten (Bropages -> Ruby, Cheat -> Python, TLDR -> Javascript, ...) sowie Platz auf der SSD/HDD hat. Eine andere Alternative wäre doch das Erstellen eigener Manpages (Beispiel) bzw. 'helper' in Form von Textdateien. Das mag besonders bei der Nutzung von wenigen und komplexen Befehlen helfen. Gruss.
Von Produktiv-Benutzer am So, 24. März 2019 um 16:20 #
Das sind hilfreiche Tips, ich hab mir die unbekannten auch gebookmarked, gibt ja von viele mehr, auch software-mässig.
Wenngleich es zuckt zu Schreiben, "es ist ein Herumdoktor'n an den Symptomen" lass ich das mal, denn es wäre genauso richtig, wie auch falsch.
Richtig ist in jedem Fall: Neue Systeme, davon noch zahlreiche, helfen nicht bei der Verbesserung der Qualität für den Benutzer. Verbesserung muss sich beim Standardsystem, also dem größten gemeinsamen Nenner ergeben. Nur dann wird eine gesteigerte Qualität auch in der Masse wahrgenommen (ja, klingt irgendwie wie eine Behauptung).
Dies würde nun im Weiteren in die Richtung gehen "warum brauchen wir soviele verschiedene Linux-System"... nein, da winke ich mal dankend ab
Ich schliesse mich Dir da an. Die Linux-Welt ist ein schöner, aber auch ein grosser Whirlpool, wo es viele gute Ideen gibt. Dabei kann - wie Du es sagst - ein Ansatz für einen User schlecht, für den anderen aber gerade recht sein. Am einfachsten ist es vermutlich diejenige Strategie zu folgen, die einen am besten zeitlich bzw. vom Aufwand her passt. Diese Strategie kann man glücklicherweise später immer ändern, wenn im Falle der Manpages das Arbeiten in der Bash z.B. beruflich an Bedeutung gewinnt. LG.
Eine andere Alternative wäre doch das Erstellen eigener Manpages (Beispiel) bzw. 'helper' in Form von Textdateien.
Kann man auch machen. Man sollte allerdings zusehen, das man davon Backups macht oder es zumindest in ein git repo packt, das extern gespeichert wird.
Hin und wieder vergisst man nämlich solche Daten, die außerhalb in /home/USERNAME liegen, wenn man eine Neuinstallation durchführen muss, z.b. weil man die SSD gewechselt hat und die alte ausgelutscht ist.
Ich persönlich mache es daher anders. Ich habe einen Order mit einfachen Textdateien. Den Textdateien gebe ich einen gut beschreibenden Namen der das Problem auf den Punkt bringt. Und in der Datei schreib ich dann die Befehle + Kommentartext rein, was ich mir merken wollte.
Wenn ich dann etwas wissen muss, listet mir ein ls die Lösungen auf und wenn ich keine Lust auf langes suchen habe, kann ich das noch mit * oder grep. Das zeigt mir schnell auf, in welcher Datei das Problem behandelt wird. Das das ganze unter /home/USERNAME liegt, vergesse ich es auch nicht davon backups anzulegen.
Der einzige Nachteil ist höchstens, dass ich zum Verzeichnis hin navigieren oder beim öffnen angeben muss. Da ist eine selbsterstellte manpage natürlich ein Vorteil. Allerdings auch nur dann, wenn man sich noch daran erinnern kann, unter welchem Namen man sie abgespeichert hat. In diesem Aspekt ist meine Lösung besser.
Ach und das neu anlegen oder editieren geht schnell von Hand. Ich brauche dafür ja nur einen Texteditor wie nano oder vim.
Ich halte es ähnlich. Das Verzeichnis heißt bei mir ~/TippsUndTricks. Mal editiere ich etwas, mal speichere ich Websites "as is" dort ab.
Dort "hin navigieren" ist nicht schwer, ein Dolphin-Fenster ist immer offen. Und als Editor dient hier wie immer Kate, da ich einen KDE-/Plasma-Desktop benutze.
Ja, manche manpages sind verwirrend und ohne Beispiel, bzw. ich bin zu blöd dazu.
Als ich neu bei Linux war, hatte ich Stunden gebraucht, um den Syntax von 'date' zu begreifen. Blödes '%' . Ein Beispiel, und alles wäre kein Thema ...
... besonders schön wird es doch dadurch, dass in Webforen alle auf gewisse gottgewollte Systematiken hinweisen und hochhalten (etwa der Sinn von doppelten vs. einfachen Anführungszeichen, oder die Konvention bezüglich -pYOURPASSWORD, oder -p YOURPASSWORD, oder -p=YOURPASSWORD, oder Reihenfolgen, Großkleinschreibung (gelegentlich zur Negation), ...), und man bei Lichte betrachtet irgendwann wieder feststellen muss: Nein, so schön ist das nur in deren Träumen. Und möglicherweise glauben die sogar selbst dran. Aber eigentlich ist es nicht wirklich einheitlich, und im Interpretieren von Kommandozeilenparametern sieht man immer wieder Kreativität.
doppelten vs. einfachen Anführungszeichen -> Sry, gemeint waren nicht Anführungszeichen, sondern Bindestriche. Die Anführungszeichen sind eine andere Geschichte, ein paar Meter weiter...
Die im POSIX-Standard festgelegte Schreibweise ist die mit einem Leerzeichen zwischen der Option und dem ihr zugehörigen Argument. Andere Varianten sind dort nur in Ausnahmefällen und aus Gründen der weiteren Verwendbarkeit von älteren Programmen gestattet.[1]
Daran, wie auch an den Rest der POSIX-Spezifikation für Kommandozeilenwerkzeuge, halten sich allerdings bei weitem nicht alle Entwickler, weshalb man schlicht damit leben müssen wird, dass es da nicht immer einheitlich zugeht.
Die Variante mit doppelten Bindestrich und Schlüsselwort ist eine GNU-spezifische Erweiterung, die im Übrigen nicht per se gegen den POSIX-Standard verstößt.[2]
Die Anführungszeichen sind Sache der Shell. Und in den meisten gängigen Unix-Shells haben "" und '' jeweils die gleiche Bedeutung.[3]
-pYOURPASSWORD, oder -p YOURPASSWORD, oder -p=YOURPASSWORD
Man könnte die Kommandozeilentools alle Deppensicher hinkriegen, wenn die Entwickler sich auf -p=YOURPASSWORD einigen würden.
Denn mit dem Gleichheitszeichen ist es wirklich Deppensicher und übersichtlich, da der Passwortstring so gut von dem Buchstaben, der für die Option zuständig ist, getrennt ist.
Von man page lyriker am Sa, 23. März 2019 um 16:43 #
Da bescheuertste bei der rar man page ist dass nicht alles drinn steht und auf eine txt-Datei verwiesen wird. rar ist da leider keine Ausnahme für diesen Schwachsinn.
unrar ist nur leider ein schlechtes Beispiel, da es sich um keine linuxspezifische Software handelt und sich unrar überall gleich (seltsam) bedienen lässt, selbst unter DOS. Allerdings kann man über die Manpage trotzdem nicht wirklich meckern: SYNOPSIS unrar <command> [-<switch 1> -<switch N>] archive [files...] [path...]
OPTIONS After the program name comes a command and then optional switches with dashes before them.
wann benutze ich sie? * wenn 5-10 min google nichts sinnvolles ergibt * wenn ich einen speziellen parameter nachschlagen will
warum nicht gleich manpages? * english ist für mich anstrengend * manpages wirken für mich unübersichtlich schwer durchdringbar - hier sind websites oftmals deutlich übersichtlicher * praktische beispiele sind oftmals einleuchtender als sich die erst die gesamte manual aneignen zu müssen
Es gibt auch deutschsprachige Manpages. Auch wenn dann leider immernoch nicht alle übersetzt sind. Es kann auch sein, dass man die deutschsprachigen Manpages zuerst installieren muss. Such mal nach dem Paket manpages-de.
Von ich bins doch nicht am Fr, 22. März 2019 um 18:58 #
auf jeden Fall nutze ich manpages und das regelmäßig... in meinem Alter kann ich mich nicht mehr alles merken - es reicht, wenn ich weiß, wo ich was nachschlagen kann..
Hallo, ich habe man pages zum Glück nie gebraucht! Also ich vor über 20 jahren mit Suse angefangen habe, waren die mitgelieferten handbücher eine Offenbarung; später bei Mandrake und Ubuntu hatte ich a. schon genug Wissen und b. gibt es PROGRAMMNAME -help .... Bei Programmen mit GUI ist die Hilfe eh eingebaut oder man findet ausreichend Sachen im Netz. Ansonsten lohnt es sich auch durchaus, mal ein buch aus Papier zu kaufen zum Nachschlagen....
- Weil Webpages einfach besser sind um mal kurz was zu finden. Maus, Scrollrad, Scrollleiste, Klick, etc. - Im Web auch auf Deutsch erklärt - Ich lieber meinen Zweitrechner, mein Handy oder ein Tablet benutze um mir das gewurschtel im man zu ersparen. f = n, weiter = N, Ctrl-c = q und so weiter. Ich ärger mich jedes mal über diese für mich willkürlichen/absurden Belegungen. Für Ärger habe ich keine Zeit und Lust. - Markieren, kopieren, etc. all das geht nicht und wenn halt nur für mich abnormal umständlich - Meist viel zu technisch und wenn im Englischen, dann halt im Zweifel mit Fachbegriffen die mir nicht 100% klar sind. Ich kann genug Englisch, im Zweifel bin ich halt kein native speaker. - Ich meist ein Problem habe und die genaue Frage noch nicht kenne. Dann brauche ich eh erst einmal die Websuche um mein Problem zu erkennen. Ich bin also schon im Web. Dann geh ich nicht danach noch in man um mir die genauen Optionen anzusehen. Ich bin halt nur Freizeitadmin.
Klar wenn ich die Bedienung dieses Biests mit der Muttermilch aufgesaugt hätte, dann wäre das wohl was anderes. Ich will mir aber die für mich stumpfsinningen Belegungen nicht merken. Das Wissen der Belegung gehört bei mir in das große rote Buch des unnützen Wissens. Als ich mit Linux angefangen hatte, habe ich dann aus Verzweiflung einen Neustart gemacht, weil ctrl-c nicht funktioniert hat und "q" einfach nicht offensichtlich ist. Ja, jetzt weiß ich es aber die Erinnerung an den Mist trage ich heute noch rum.
Und ganz im Zweifel bekomme ich die Manpage auch im Internet, dann aber mit , Maus und einem Ausknopf.
Weil Webpages einfach besser sind um mal kurz was zu finden.
Außer natürlich diese ganzen schrottigen Web-2.0-Seiten, die mitunter Javascript benötigen, um überhaupt etwas (auf Dauer) anzuzeigen und deren Ressourcenverbrauch einigermaßen irre ist.
Maus, Scrollrad, Scrollleiste, Klick, etc.
Mir scheint, mit Cursortasten, Bild auf/ab, Ende- und Pos1-Taste lässt sich oft entspannter und effektiver navigieren.
Im Web auch auf Deutsch erklärt
Unter vielen Linux-Systemen haben die meisten Handbuchseiten, soweit mir bekannt, eine deutsche Übersetzung.
f = n, weiter = N, Ctrl-c = q und so weiter. Ich ärger mich jedes mal über diese für mich willkürlichen/absurden Belegungen. [...] Ich will mir aber die für mich stumpfsinningen Belegungen nicht merken. Das Wissen der Belegung gehört bei mir in das große rote Buch des unnützen Wissens.
Wer entschieden nichts davon wissen will, wie ein Programm bedient wird, wird bei der Bedienung natürlich seine Schwierigkeiten haben.
Stumpfsinnig sind die Tastenbelegungen von less jedenfalls mit Sicherheit nicht. Wie nämlich die Handbuchseite verrät, basieren die „sowohl auf more als auch vi“, also auf den Kommandos des ehemaligen Standardpagers sowie des nach wie vor aktuellen Standardtexteditors unter Unix-Systemen. (Standard in dem Sinn, dass man darauf zählen kann, dass er da ist, auch wenn man ihn nicht benutzen mag.)
Markieren, kopieren, etc. all das geht nicht und wenn halt nur für mich abnormal umständlich
Zumindest was Terminalemulatoren unter X11 betrifft, lässt sich Text sehr einfach kopieren, nämlich indem man ihn mit der Maus markiert und dann die mittlere Maustaste zum Einfügen benutzt. Mit der rechten Maustaste lassen sich Markierungen auch Stück für Stück setzen. Auf Tabletten könnte das aber möglicherweise schwierig sein.
Stumpfsinnig sind die Tastenbelegungen von less jedenfalls mit Sicherheit nicht. Wie nämlich die Handbuchseite verrät, basieren die „sowohl auf more als auch vi“, also auf den Kommandos des ehemaligen Standardpagers sowie des nach wie vor aktuellen Standardtexteditors unter Unix-Systemen. (Standard in dem Sinn, dass man darauf zählen kann, dass er da ist, auch wenn man ihn nicht benutzen mag.)
Man könnte allerdings auch mal die Cursortasten als zusätzliche Eingabemöglichkeit einbauen, damit es vor allem Anfänger nicht so schwer haben. Cursortasten gibt es, mit ein paar wenigen Ausnahmen, heutzutage selbst an Notebooktatstaturen. Und für die Ausnahmen hätte man dann die alten Tastenkombinationen als Alternative.
Von Produktiv-Benutzer am So, 24. März 2019 um 07:49 #
Als Haupt-Mangel gestatelt sich die auf reine "Text finden" ausgelegt Art der Suche.
Bei einer Wissensdatenbank handelt es sich um abstrakte Inhalte. Also sollte man auch Abstraktionen formulieren können, die man sucht. Oder eine Navigation die "Abstraktions-Häppchen" berücksichtigen.
"Info" ist das zwar etwas weiter, aber eben irgendwie gruseliger zu bedienen. IMHO.
Was bedeutet "Abstraktion"? Es geht um Befehle, Schalter, Parameter, Konzepte, Fehler usw.
Als Nutzer denke ich in "springe zu Konzept x" und nicht "suche irgendwas das zu dem Text Konzept passt".
Dies als Ergänzung zum ursprünglichen Beitragsfaden.
Ja, das stimmt schon. Allerdings wird dieser Mangel wiederum dadurch etwas ausgeglichen, dass man pages normalerweise einer bestimmten Struktur folgen. Wenn ich beispielsweise wissen will, welche Dateien für die Konfiguration eines Programms relevant sind, finde ich die Antwort zumeist im Abschnitt FILES (bzw. DATEIEN in deutschsprachigen Varianten). Da die Überschriften der Abschnitte in Großbuchstaben geschrieben sind, lassen die sich auch recht einfach finden.
Von Produktiv-Benutzer am So, 24. März 2019 um 16:37 #
normalerweise Diesen Gedankengang hatte ich beim Verfassen meines ersten Beitrags in dieser Umfrage.
Daraus ergab sich die Idee, nach einem Werkzeug, das automatisiert die man-pages im System darauf überprüft, ob sie "Standard-Sektionen" liefern und ob insbesondere eine Beispiel-Sektion vorhanden ist.
Das könnte man z.B. auch selbst als Entwickler nutzen, ins makefile integriert, würde so die Dokumentation automatisch überprüft.
Dies nur als oberflächlicher Test. Weiter könnte man man-pages (wenn durch selbe unterstützt) darauf abklopfen, automatisiert aus dem angegebenen Befehl Beispiele zu erzeugen. (so wie ungefähr wie make dependend). Oder man könnte man-pages automatische splitten, in Einsteiger / Fortgeschrittene / "Schnellgucker"
Die Idee biete viele Ansätze für drastische Qualitätsverbesserungen.
Vielleicht gibt's ja bereits Programme, die mir nicht bekannt sind ??
Manpages oftmals keine Fallbeispiele angeben, die oft angewendet werden. Als Beispiel nehme ich mal journalctl. Dort gibt es zwar Beispiele, aber eines der wichtigsten fehlt: kritische Fehler anzeigen. Durch Internet bin ich dann schnell auf das hier gestoßen: journalctl -p err -b und bäm, Fehler gefunden.
Je nach Anwendung ist --help oft besser dargestellt (wenn man überhaupt Inhalt hat), und es ist für die Entwickler auch einfacher soetwas bereitzustellen, gerade wenn man an all die go binaries, rubygems, npm, und so denkt. Selbst wenn die man pages hätten, würde der simple Installationspfad sie nicht mit installieren.
Mit --help bekommst du aber meist nur die möglichen Optionen aufgelistet. Wobei es nichtmal unbedingt alle sein müssen, wenn die Liste sehr umfangreich ist. In den man/info pages findest du dann deutlich mehr Information. Für einen Entwickler ist das jetzt auch nicht gerade ein Riesenaufwand eine Dokumentation bereitzustellen. Teilweise geht es sogar automatisch, in dem ich z.B. mit einem Script/Tool die Kommentare auswerte.
...bevor ich im IRC oder im Forum einen Artikel verfasse dann schon. Es hängt natürlich von der Problemstellung ab. Manpages sind nicht das Allerheilmittel, aber sie helfen weiter.
Hilfe/Infoseiten im Web nutzen? Klar! Sowas zum Beispiel:
Linupedia
Support-Wiki für (nicht nur) openSUSE Linux
https://linux-club.de/wiki/opensuse/Hauptseite
oder Foren wie z.B. das:
https://www.linuxmintusers.de/index.php
Einfach aus Neugier reinklicken ,
bei irgend einem Thema lese ich mich dann fest.
Ist mir lieber als im Internetz herumzusuchen, wo einem immer mehr Schrott präsentiert wird, aus dem man die brauchbaren Seiten raussuchen muss.
Dito. Bei mir sind Man-Pages der zweite Anlaufpunkt nach -h und --help.
1. Anlauf: -h und --help
2. Anlauf man page
3. Anlauf (manchmal auch "vorgezogen") Tante Google fragen; mit Stichwörtern die mein Verständnis-Problem ausmachen.
Dabei kommt es auch vor, dass ich auf diesem Wege eine Manpage lese, die irgendwo auf einer Webseite steht. Zwei Vorteile dabei: scrollen und Ausschnitt wählen ist leichter, und zweitens von der Schrift her fällt mir das manchmal leichter, den (englischen) Text zu lesen, als im Terminal-Fenster.
k/t
deutlicher und hilfreicher.
Was also ist nicht "schick" an man-pages?
Zur eigentlichen Frage: Ja, gerne und sehr regelmässig.
Persönliches Fazit: Lokal verfügbare Dokumentation auf hohem Niveau ist sicher eine Schwachstelle der Benutzer-Erfahrung im Umgang mit Linux(als Betriebssystem nicht Kernel).
Die _Erfahrung_ eines Benutzers hat wenig mit der lokal verfügbaren Dokumentation zu tun – das Erlebnis schon eher.
Ich dachte "User Experience" sei ein feststehender Begriff für alles,
was den Nutzer und seine Erlebnisse beim Bedienen des System betrifft.
Wenn also Qualität der Dokumentation nicht gut, dann hat der Nutzer schlechte Erfahrung.
Zum Beispiel, weil er viel zu lange braucht, etwas zu finden und das schlicht, weil die Man-Page schlecht strukturiert ist
und für Einsteiger tödlich: Keine Beispiele liefert.
Und die Übersetzung hätte ich mal im vorherigen Beitrag mit einfügen sollen:
https://www.google.com/search?q=%22user+experience%22+%C3%BCbersetzung
Aber ich glaube Wortklauberei verwässert das angesprochene Problem.
_Experience_ hat im Deutschen nicht nur eine Übesetzung – und je nach Fall ist eben nicht jede korrekt (https://dict.leo.org/englisch-deutsch/experience). Wenn auch viele falsch übersetzen, macht es das dennoch (noch) nicht richtig. In 100 Jahren ist das vermutlich völlig korrektes Deutsch – aber daran möchte ich dann bitte keine Mitschuld tragen ;)
In der Sache hast Du natürlich recht – auch damit, dass Wortklauberei nichts zur Lösung beiträgt. Aber ich kriege regelmäßig die Krise, wenn ich _Benutzererfahrung_ oder _Expertise_ etc. „falsch“ verwendet sehe … Mein Problem … aber „Euer“ Fehler
Es liegt mir fern, durch Wortwahl Krisen zu verursachen. Sad Fact: In der Realität ist das oft der Fall. Die allermeisten Mitmenschen kümmern sich nicht um sprachliche Exaktheit. Damit meine ich nicht "von oben herab"-Sprech, sondern das Bewusstsein, dass man ständig Fehler macht, aber "auch mal nachschauen könnte", wenn dem mal wieder so war.
Damit sind wir beim von Dir angesprochenen Folge-Problem: "Nachschauen" und "viele verschiedene Möglichkeiten" führen nicht zum einen eindeutigen Ergebnis.
2019 ist nicht perfekt.
Ein generelles Problem mit den klassischen Unix-Handbuchseiten unter GNU/Linux ist, dass das GNU-Projekt primär ein anderes System zur Dokumentation seiner Software verwendet, nämlich GNU Info, und auch explizit erklärt, dass man pages unter GNU sekundär sind.[1]
Das heißt, wenn sich der Entwickler einer GNU-Software dazu entscheidet, keine klassische Handbuchseite mitzuliefern, gibt's die solange nicht, bis sie irgendwer anders schreibt. Das scheint auch ein gewichtiger Grund für das Fehlen von Beispielen in man pages unter GNU/Linux zu sein.
Allerdings hatte die Quasi-Ersetzung der man pages durch info pages unter GNU offenbar auch ein paar vernünftige Gründe und ist nicht der schiere Irrsinn, als der sie oft dargestellt wird.
Gut, dann hier zur allgemeinen Lebenszeitersparnis ein kleiner Spickzettel für
less:/→ Suchwort eingeben → EnterKannst du ein paar Handbuchseiten nennen, in denen das der Fall ist? Dann könnte man die mal mit dem vergleichen, was verschiedene BSD-Varianten und Solaris im jeweiligen Fall bieten.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Mär 2019 um 23:21.Der Irrsinn ist, dass das eigentliche GNU Tool, um diese GNU Info Seiten zu lesen, bei der Usability Jahre zurückliegt.
Was dazu führte, dass einige Entwickler alternative Clients dazu schrieben.
Sinnvoller wäre es aber gewesen, den GNU Client auf Vordermann zu bringen.
Das info System hat nochmal eine eigene Benutzerschnittstelle. Das bedeutet wieder zusätzliche Lern-Arbeit, um an mehr Informationen zu kommen.
Leider ist der gängige Weg, um sich das zu ersparen "raus aus dem System, rein ins Netz" (was natürlich zeitlich auch nicht eingegrenzt werden kann, wenn man die Suche startet).
Ein direktes Beispiel ist "man grep" (deutsche Seite, keine Beispiele).
Über man 1posix grep oder info grep kommt man natürlich zum Ziel.
Aber der übliche Kommentar (ähnlich rtfm) ist ja "lies die Man-Page".
"Na toll", denkt man sich lange Zeit.
Man page != Man Page und damit auch nicht eindeutig
Eine sehr wichtige Sache im täglichen Leben, auch wenn man irgendwelche Zeilen von anderen Leuten sieht,
ist die Antwort auf "Was macht der Parameter denn?".
Dafür muss man halt konstruieren, sonst sucht man sich zu Tode.
also "/^ +-c" z.B. für einen -c Parameter. Ist nicht Anfänger-Niveau, aber RegEx sind natürlich, sobald man sie kann, sehr nützlich.
Ich wusste nicht, wie man das Zitat schön formatieren kann, deswegen habe ich so getippt. Sorry dafür.
Allgemein find ich halt, dass genau die Dokumentation das Kernstück für die Akzeptanz beim Nutzer ist.
Das manpage System war eine Offenbarung, als ich das erste Mal mit in Berührung kam.
Aber im täglichen Leben gehört viel Frickelei dazu, innerhalb kurzer Zeit ein eindeutiges Resultat zu bekommen.
Viel schlimmer wird's ja, wenn Konzepte betroffen sind und nicht einzelne Parameter.
Dann sucht man sich zu Tode, welche Auswirkungen LC_ALL z.B. auf was alles hat.
Benutzt wirklich jemand GNU Info? Hab schon mal davon gehört, es aber nie ernsthaft verwendet und auch alle Kollegen die unter Linux arbeiten lesen nur die Manpages. Ich habe nicht den Eindruck, dass die Manpages durch GNU Info ersetzt werden. Auch in WIkis oder in Foren wird meist nur auf die Manpages verwiesen.
Ich meinte damit lediglich den programmatischen Ansatz des GNU-Projekts, man pages als primäres Format der Systemdokumentation durch Texinfo-Seiten und einen entsprechenden Browser zu ersetzen, nicht die reale Situation unter GNU/Linux.
Ich nutze GNU Info übrigens nicht.
welchen Browser, soll ich denn an der Konsole benutzen, der einfacher zu bedienen ist als ne Manpage mit den vielleicht 6 Tasten?
Das kann ich dir nicht beatworten. Ich nutze nur die klassischen Handbuchseiten und die Hilfetexte, die viele Programme per
--helpausgeben, ansonsten WWW.Der Standardbrowser für Texinfo-Seiten heißt
info.Im Übrigen wird nicht die man page bedient, sondern der Pager.
Wer nur gelegentlich die GNU Info-Seiten nutzt für den dürfte sich wegen der einfacheren Bedienung pinfo anbieten.
Sehr guter Tip. Die wesentlich verbesserte Navigation zu den Themen-Links (und damit eine Art Abstraktionsmöglichkeit) haben mich sofort verliebt werden lassen.
Installiere dir auch gleich noch htop, dann hast du eine wesentlich übersichtlichere Alternative zu top.
Ich schon, weil die Dokumentation über info meist deutlich ausführlicher ist, als so manche manpage.
Wären hier nicht Bropages, Cheat, TLDR et al. eine Lösung, welche Beispiele für die unterschiedlichen Befehle auflisten? Natürlich sofern man keine Probleme mit der Installation weiterer Abhängigkeiten (Bropages -> Ruby, Cheat -> Python, TLDR -> Javascript, ...) sowie Platz auf der SSD/HDD hat. Eine andere Alternative wäre doch das Erstellen eigener Manpages (Beispiel) bzw. 'helper' in Form von Textdateien. Das mag besonders bei der Nutzung von wenigen und komplexen Befehlen helfen. Gruss.
Das sind hilfreiche Tips, ich hab mir die unbekannten auch gebookmarked, gibt ja von viele mehr, auch software-mässig.
Wenngleich es zuckt zu Schreiben, "es ist ein Herumdoktor'n an den Symptomen" lass ich das mal, denn es wäre genauso richtig, wie auch falsch.
Richtig ist in jedem Fall: Neue Systeme, davon noch zahlreiche, helfen nicht bei der Verbesserung der Qualität für den Benutzer. Verbesserung muss sich beim Standardsystem, also dem größten gemeinsamen Nenner ergeben. Nur dann wird eine gesteigerte Qualität auch in der Masse wahrgenommen (ja, klingt irgendwie wie eine Behauptung).
Dies würde nun im Weiteren in die Richtung gehen "warum brauchen wir soviele verschiedene Linux-System"... nein, da winke ich mal dankend ab
Ich schliesse mich Dir da an. Die Linux-Welt ist ein schöner, aber auch ein grosser Whirlpool, wo es viele gute Ideen gibt. Dabei kann - wie Du es sagst - ein Ansatz für einen User schlecht, für den anderen aber gerade recht sein. Am einfachsten ist es vermutlich diejenige Strategie zu folgen, die einen am besten zeitlich bzw. vom Aufwand her passt. Diese Strategie kann man glücklicherweise später immer ändern, wenn im Falle der Manpages das Arbeiten in der Bash z.B. beruflich an Bedeutung gewinnt. LG.
Kann man auch machen. Man sollte allerdings zusehen, das man davon Backups macht oder es zumindest in ein git repo packt, das extern gespeichert wird.
Hin und wieder vergisst man nämlich solche Daten, die außerhalb in /home/USERNAME liegen, wenn man eine Neuinstallation durchführen muss, z.b. weil man die SSD gewechselt hat und die alte ausgelutscht ist.
Ich persönlich mache es daher anders.
Ich habe einen Order mit einfachen Textdateien.
Den Textdateien gebe ich einen gut beschreibenden Namen der das Problem auf den Punkt bringt.
Und in der Datei schreib ich dann die Befehle + Kommentartext rein, was ich mir merken wollte.
Wenn ich dann etwas wissen muss, listet mir ein ls die Lösungen auf und wenn ich keine Lust auf langes suchen habe, kann ich das noch mit * oder grep.
Das zeigt mir schnell auf, in welcher Datei das Problem behandelt wird.
Das das ganze unter /home/USERNAME liegt, vergesse ich es auch nicht davon backups anzulegen.
Der einzige Nachteil ist höchstens, dass ich zum Verzeichnis hin navigieren oder beim öffnen angeben muss.
Da ist eine selbsterstellte manpage natürlich ein Vorteil. Allerdings auch nur dann, wenn man sich noch daran erinnern kann, unter welchem Namen man sie abgespeichert hat.
In diesem Aspekt ist meine Lösung besser.
Ach und das neu anlegen oder editieren geht schnell von Hand. Ich brauche dafür ja nur einen Texteditor wie nano oder vim.
Danke für Deine Hinweise !
Da gibt es noch einiges auszuprobieren
Ich halte es ähnlich. Das Verzeichnis heißt bei mir ~/TippsUndTricks.
Mal editiere ich etwas, mal speichere ich Websites "as is" dort ab.
Dort "hin navigieren" ist nicht schwer, ein Dolphin-Fenster ist immer offen. Und als Editor dient hier wie immer Kate, da ich einen KDE-/Plasma-Desktop benutze.
Ja, manche manpages sind verwirrend und ohne Beispiel, bzw. ich bin zu blöd dazu.
Als ich neu bei Linux war, hatte ich Stunden gebraucht, um den Syntax von 'date' zu begreifen. Blödes '%' . Ein Beispiel, und alles wäre kein Thema ...
Manpage einfach bis zum Ende lesen
leider sind diese meistens zu kryptisch für einfache Nutzer.
Schlechtes Beispiel:
unrar
e extract
-ppassword
Woher weiß ich dass "e" ohne "-" benutzt wird und "-p" mit Bindestrich, dass Passwort aber ohne Anführungszeichen und direkt hinter das "-p"?!
Klar, Profis erkennen das sofort weil es ja auch so da steht, aber was spricht gegen schöne Beispiele (und besser noch ein paar Beispiele?)
unrar extract with-password file
unrar e -pYOURPASSWORD file.part1.rar
Schönen DAU-Gruß
Das erlernt man mit der Zeit. Es wird häufiger zwischen Kommandos und Optionen getrennt. Kommandos sind dann ohne - und Optionen mit -.
... besonders schön wird es doch dadurch, dass in Webforen alle auf gewisse gottgewollte Systematiken hinweisen und hochhalten (etwa der Sinn von doppelten vs. einfachen Anführungszeichen, oder die Konvention bezüglich -pYOURPASSWORD, oder -p YOURPASSWORD, oder -p=YOURPASSWORD, oder Reihenfolgen, Großkleinschreibung (gelegentlich zur Negation), ...), und man bei Lichte betrachtet irgendwann wieder feststellen muss: Nein, so schön ist das nur in deren Träumen. Und möglicherweise glauben die sogar selbst dran. Aber eigentlich ist es nicht wirklich einheitlich, und im Interpretieren von Kommandozeilenparametern sieht man immer wieder Kreativität.
doppelten vs. einfachen Anführungszeichen -> Sry, gemeint waren nicht Anführungszeichen, sondern Bindestriche. Die Anführungszeichen sind eine andere Geschichte, ein paar Meter weiter...
Die im POSIX-Standard festgelegte Schreibweise ist die mit einem Leerzeichen zwischen der Option und dem ihr zugehörigen Argument. Andere Varianten sind dort nur in Ausnahmefällen und aus Gründen der weiteren Verwendbarkeit von älteren Programmen gestattet.[1]
Daran, wie auch an den Rest der POSIX-Spezifikation für Kommandozeilenwerkzeuge, halten sich allerdings bei weitem nicht alle Entwickler, weshalb man schlicht damit leben müssen wird, dass es da nicht immer einheitlich zugeht.
Die Variante mit doppelten Bindestrich und Schlüsselwort ist eine GNU-spezifische Erweiterung, die im Übrigen nicht per se gegen den POSIX-Standard verstößt.[2]
Die Anführungszeichen sind Sache der Shell. Und in den meisten gängigen Unix-Shells haben
""und''jeweils die gleiche Bedeutung.[3]Man könnte die Kommandozeilentools alle Deppensicher hinkriegen, wenn die Entwickler sich auf -p=YOURPASSWORD
einigen würden.
Denn mit dem Gleichheitszeichen ist es wirklich Deppensicher und übersichtlich, da der Passwortstring so gut von dem Buchstaben, der für die Option zuständig ist, getrennt ist.
.. und die Zuweisung durch das Gleichheitszeichen deutlich erkennbar ist.
Was bei einem Leerzeichen nicht der Fall ist.
Woher weiß ich dass "e" ohne "-" benutzt wird und "-p" mit Bindestrich, dass Passwort aber ohne Anführungszeichen und direkt hinter das "-p"?!
man pages sind eine Referenz, kein Lehrbuch.
Da bescheuertste bei der rar man page ist dass nicht alles drinn steht und auf eine txt-Datei verwiesen wird.
rar ist da leider keine Ausnahme für diesen Schwachsinn.
unrar ist nur leider ein schlechtes Beispiel, da es sich um keine linuxspezifische Software handelt und sich unrar überall gleich (seltsam) bedienen lässt, selbst unter DOS. Allerdings kann man über die Manpage trotzdem nicht wirklich meckern:
SYNOPSIS
unrar <command> [-<switch 1> -<switch N>] archive [files...] [path...]
OPTIONS
After the program name comes a command and then optional switches with dashes before them.
wann benutze ich sie?
* wenn 5-10 min google nichts sinnvolles ergibt
* wenn ich einen speziellen parameter nachschlagen will
warum nicht gleich manpages?
* english ist für mich anstrengend
* manpages wirken für mich unübersichtlich schwer durchdringbar - hier sind websites oftmals deutlich übersichtlicher
* praktische beispiele sind oftmals einleuchtender als sich die erst die gesamte manual aneignen zu müssen
Es gibt auch deutschsprachige Manpages. Auch wenn dann leider immernoch nicht alle übersetzt sind. Es kann auch sein, dass man die deutschsprachigen Manpages zuerst installieren muss. Such mal nach dem Paket
manpages-de.Folgende Option sollte dir die Man Page in Deutsch anzeigen, sofern du das deutschsprachigen Manpage Pakete manpages-de installiert hast.
Insofern ist die Sprache, sofern die deutschsprachige Manpage aktuell genug ist und eine für das jeweilige Programm vorhanden ist, kein Problem.
auf jeden Fall nutze ich manpages und das regelmäßig... in meinem Alter kann ich mich nicht mehr alles merken - es reicht, wenn ich weiß, wo ich was nachschlagen kann..
Klar nutze ich man pages, aber was mich viel eher interessieren würde, wer nutzt die GNU info Seiten?
Kann man installierte man pages lokal im Browser anzeigen lassen?
Ja, mit der Option --html
Hallo, ich habe man pages zum Glück nie gebraucht!
Also ich vor über 20 jahren mit Suse angefangen habe, waren die mitgelieferten handbücher eine Offenbarung; später bei Mandrake und Ubuntu hatte ich a. schon genug Wissen und b. gibt es PROGRAMMNAME -help ....
Bei Programmen mit GUI ist die Hilfe eh eingebaut oder man findet ausreichend Sachen im Netz.
Ansonsten lohnt es sich auch durchaus, mal ein buch aus Papier zu kaufen zum Nachschlagen....
- Weil Webpages einfach besser sind um mal kurz was zu finden. Maus, Scrollrad, Scrollleiste, Klick, etc.
- Im Web auch auf Deutsch erklärt
- Ich lieber meinen Zweitrechner, mein Handy oder ein Tablet benutze um mir das gewurschtel im man zu ersparen. f = n, weiter = N, Ctrl-c = q und so weiter. Ich ärger mich jedes mal über diese für mich willkürlichen/absurden Belegungen. Für Ärger habe ich keine Zeit und Lust.
- Markieren, kopieren, etc. all das geht nicht und wenn halt nur für mich abnormal umständlich
- Meist viel zu technisch und wenn im Englischen, dann halt im Zweifel mit Fachbegriffen die mir nicht 100% klar sind. Ich kann genug Englisch, im Zweifel bin ich halt kein native speaker.
- Ich meist ein Problem habe und die genaue Frage noch nicht kenne. Dann brauche ich eh erst einmal die Websuche um mein Problem zu erkennen. Ich bin also schon im Web. Dann geh ich nicht danach noch in man um mir die genauen Optionen anzusehen. Ich bin halt nur Freizeitadmin.
Klar wenn ich die Bedienung dieses Biests mit der Muttermilch aufgesaugt hätte, dann wäre das wohl was anderes. Ich will mir aber die für mich stumpfsinningen Belegungen nicht merken. Das Wissen der Belegung gehört bei mir in das große rote Buch des unnützen Wissens.
Als ich mit Linux angefangen hatte, habe ich dann aus Verzweiflung einen Neustart gemacht, weil ctrl-c nicht funktioniert hat und "q" einfach nicht offensichtlich ist. Ja, jetzt weiß ich es aber die Erinnerung an den Mist trage ich heute noch rum.
Und ganz im Zweifel bekomme ich die Manpage auch im Internet, dann aber mit , Maus und einem Ausknopf.
Weiter oben hat jemand die wesentlichen pager-Befehle aufgezeigt:
Find' ich nicht sonderlich schwer, das zu lernen.
Außer natürlich diese ganzen schrottigen Web-2.0-Seiten, die mitunter Javascript benötigen, um überhaupt etwas (auf Dauer) anzuzeigen und deren Ressourcenverbrauch einigermaßen irre ist.
Mir scheint, mit Cursortasten, Bild auf/ab, Ende- und Pos1-Taste lässt sich oft entspannter und effektiver navigieren.
Unter vielen Linux-Systemen haben die meisten Handbuchseiten, soweit mir bekannt, eine deutsche Übersetzung.
Wer entschieden nichts davon wissen will, wie ein Programm bedient wird, wird bei der Bedienung natürlich seine Schwierigkeiten haben.
Stumpfsinnig sind die Tastenbelegungen von
lessjedenfalls mit Sicherheit nicht. Wie nämlich die Handbuchseite verrät, basieren die „sowohl aufmoreals auchvi“, also auf den Kommandos des ehemaligen Standardpagers sowie des nach wie vor aktuellen Standardtexteditors unter Unix-Systemen. (Standard in dem Sinn, dass man darauf zählen kann, dass er da ist, auch wenn man ihn nicht benutzen mag.)Zumindest was Terminalemulatoren unter X11 betrifft, lässt sich Text sehr einfach kopieren, nämlich indem man ihn mit der Maus markiert und dann die mittlere Maustaste zum Einfügen benutzt. Mit der rechten Maustaste lassen sich Markierungen auch Stück für Stück setzen. Auf Tabletten könnte das aber möglicherweise schwierig sein.
Hier noch was zum Schmökern: https://en.wikipedia.org/wiki/Computer_rage
Man könnte allerdings auch mal die Cursortasten als zusätzliche Eingabemöglichkeit einbauen, damit es vor allem Anfänger nicht so schwer haben.
Cursortasten gibt es, mit ein paar wenigen Ausnahmen, heutzutage selbst an Notebooktatstaturen.
Und für die Ausnahmen hätte man dann die alten Tastenkombinationen als Alternative.
Als Haupt-Mangel gestatelt sich die auf reine "Text finden" ausgelegt Art der Suche.
Bei einer Wissensdatenbank handelt es sich um abstrakte Inhalte. Also sollte man auch Abstraktionen formulieren können, die man sucht. Oder eine Navigation die "Abstraktions-Häppchen" berücksichtigen.
"Info" ist das zwar etwas weiter, aber eben irgendwie gruseliger zu bedienen. IMHO.
Was bedeutet "Abstraktion"? Es geht um Befehle, Schalter, Parameter, Konzepte, Fehler usw.
Als Nutzer denke ich in "springe zu Konzept x" und nicht "suche irgendwas das zu dem Text Konzept passt".
Dies als Ergänzung zum ursprünglichen Beitragsfaden.
Ja, das stimmt schon. Allerdings wird dieser Mangel wiederum dadurch etwas ausgeglichen, dass man pages normalerweise einer bestimmten Struktur folgen. Wenn ich beispielsweise wissen will, welche Dateien für die Konfiguration eines Programms relevant sind, finde ich die Antwort zumeist im Abschnitt FILES (bzw. DATEIEN in deutschsprachigen Varianten). Da die Überschriften der Abschnitte in Großbuchstaben geschrieben sind, lassen die sich auch recht einfach finden.
normalerweise Diesen Gedankengang hatte ich beim Verfassen meines ersten Beitrags in dieser Umfrage.
Daraus ergab sich die Idee, nach einem Werkzeug, das automatisiert die man-pages im System darauf überprüft,
ob sie "Standard-Sektionen" liefern und ob insbesondere eine Beispiel-Sektion vorhanden ist.
Das könnte man z.B. auch selbst als Entwickler nutzen, ins makefile integriert, würde so die Dokumentation automatisch überprüft.
Dies nur als oberflächlicher Test. Weiter könnte man man-pages (wenn durch selbe unterstützt) darauf abklopfen, automatisiert aus dem angegebenen Befehl Beispiele zu erzeugen. (so wie ungefähr wie make dependend). Oder man könnte man-pages automatische splitten, in Einsteiger / Fortgeschrittene / "Schnellgucker"
Die Idee biete viele Ansätze für drastische Qualitätsverbesserungen.
Vielleicht gibt's ja bereits Programme, die mir nicht bekannt sind ??
Die tun bei
lessschon genau das, was man üblicherweise erwarten würde.Manpages oftmals keine Fallbeispiele angeben, die oft angewendet werden. Als Beispiel nehme ich mal
journalctl. Dort gibt es zwar Beispiele, aber eines der wichtigsten fehlt: kritische Fehler anzeigen. Durch Internet bin ich dann schnell auf das hier gestoßen:journalctl -p err -bund bäm, Fehler gefunden.Je nach Anwendung ist --help oft besser dargestellt (wenn man überhaupt Inhalt hat), und es ist für die Entwickler auch einfacher soetwas bereitzustellen, gerade wenn man an all die go binaries, rubygems, npm, und so denkt. Selbst wenn die man pages hätten, würde der simple Installationspfad sie nicht mit installieren.
Mit --help bekommst du aber meist nur die möglichen Optionen aufgelistet. Wobei es nichtmal unbedingt alle sein müssen, wenn die Liste sehr umfangreich ist. In den man/info pages findest du dann deutlich mehr Information. Für einen Entwickler ist das jetzt auch nicht gerade ein Riesenaufwand eine Dokumentation bereitzustellen. Teilweise geht es sogar automatisch, in dem ich z.B. mit einem Script/Tool die Kommentare auswerte.
Was meinst du mit "simple Installationspfad"?
.... a man after midnight @0:30
:D