Warum gibt es auf Manpages keine Beispiele?


52

Gibt es einen Grund, warum die meisten Manpages nicht einige gängige Beispiele enthalten? Sie erklären normalerweise alle möglichen Optionen, aber das macht es für einen Anfänger noch schwieriger zu verstehen, wie es "normalerweise" verwendet wird.


1
Ich vermute, dass sie wertvollen Speicherplatz sparen wollten, etwa um den CR loszuwerden. Vgl. Beckett, Watt , S.8: "Durch die [...] Vermeidung des plethorischen Reflexivpronomen nach say wurde viel wertvoller Platz gespart ."
Peter - Reinstate Monica

3
Eine versuchte Problemumgehung für dieses Problem ist tldr-pages.github.io , obwohl ich nicht verstehe , warum sie es einfach machen, alles für den Offline-Zugriff im Voraus herunterzuladen.
Nathan Long

man jqhat über 1000 Beispielzeilen (auf Ubuntu 16.04)
Motte001

Antworten:


49

Das hängt von den Manpages ab ... Traditionell haben sie einen Abschnitt mit Beispielen enthalten - aber aus irgendeinem Grund fehlt dies normalerweise in den Manpages unter Linux (und ich gehe davon aus, dass andere GNU-Befehle verwendet werden - das sind die meisten dieser Tage). Auf Solaris hingegen enthält fast jede Manpage den Abschnitt Example, häufig mit mehreren Beispielen.

Wenn ich raten sollte, hat FSF / GNU lange Zeit davon abgeraten, manSeiten zu verwenden, und Benutzer ziehen es vor, stattdessen Informationen für die Dokumentation zu verwenden. infoSeiten sind in der Regel umfassender als man - Seiten zu sein, und in der Regel keine Beispiele umfassen. infoSeiten sind auch "aktueller" - dh verwandte Befehle (z. B. Befehle zum Suchen von Dateien) können oft zusammen gefunden werden.

Ein weiterer Grund kann sein, dass GNU und seine manSeiten auf vielen verschiedenen Betriebssystemen verwendet werden, die sich voneinander unterscheiden können (es gibt schließlich viele Unterschiede nur zwischen verschiedenen Linux-Distributionen). Die Absicht könnte gewesen sein, dass der Verlag Beispiele hinzufügte, die für das jeweilige Betriebssystem / die jeweilige Distribution relevant sind - was offensichtlich selten der Fall ist.

Ich würde auch hinzufügen, dass manSeiten niemals dazu gedacht waren, "Anfänger zu unterrichten". UNIX wurde von Computerfachleuten (alter Begriff "Hacker") entwickelt und soll von Computerfachleuten verwendet werden. Die Handbuchseiten wurden daher nicht erstellt, um Anfänger zu unterrichten, sondern um einem Computerexperten schnell zu helfen, der eine Erinnerung für eine undurchsichtige Option oder ein seltsames Dateiformat benötigte - und dies spiegelt sich in der Aufteilung einer Handbuchseite wider.

man-Seiten sind also gedacht als

  • Eine Kurzreferenz, um Ihr Gedächtnis aufzufrischen. Zeigt an, wie der Befehl aufgerufen werden soll, und listet die verfügbaren Optionen auf.
  • Eine ausführliche und in der Regel sehr technische Beschreibung aller Aspekte des Befehls. Es wurde von Computerexperten für Computerkollegen geschrieben.
  • Liste der Umgebungsvariablen und -dateien (dh Konfigurationsdateien), die vom Befehl verwendet werden.
  • Verweis auf andere Dokumentation (z. B. Bücher) und andere manSeiten - z. für das Format von Konfigurationsdateien und verwandten / ähnlichen Befehlen.

Trotzdem stimme ich Ihnen sehr zu, dass manSeiten Beispiele enthalten sollten, da sie die Verwendung besser erklären können als das Durchblättern der Manpage. Schade, dass Beispiele auf Linux- manSeiten im Allgemeinen nicht verfügbar sind ...

Beispiel für den Beispielteil einer Solaris-Manpage - zfs (1M):

(...)
Beispiele
     Beispiel 1 Erstellen einer ZFS-Dateisystemhierarchie

     Die folgenden Befehle erstellen ein Dateisystem mit dem Namen pool / home
     und ein Dateisystem namens pool / home / bob. Der Einhängepunkt
     / export / home ist für das übergeordnete Dateisystem festgelegt und lautet
     automatisch vom untergeordneten Dateisystem geerbt.

       # zfs erstelle pool / home
       # zfs set mountpoint = / export / home pool / home
       # zfs create pool / home / bob

     Beispiel 2 Erstellen eines ZFS-Snapshots

     Der folgende Befehl erstellt einen Snapshot mit dem Namen "gestern".
     Dieser Snapshot wird bei Bedarf im .zfs / Snapshot bereitgestellt
     Verzeichnis im Stammverzeichnis des Dateisystems pool / home / bob.

       # zfs snapshot pool / home / bob @ gestern

     Beispiel 3 Erstellen und Löschen mehrerer Snapshots

     Mit dem folgenden Befehl werden Snapshots mit dem Namen "gestern von" erstellt
     pool / home und alle untergeordneten Dateisysteme. Jeder
     Der Snapshot wird bei Bedarf im Verzeichnis .zfs / snapshot bereitgestellt
     an der Wurzel seines Dateisystems. Der zweite Befehl zerstört
     die neu erstellten Schnappschüsse.

       # zfs snapshot -r pool / home @ gestern
       # zfs destroy -r pool / home @ gestern

SunOS 5.11 Letzte Änderung: 23. Juli 2012 51

Systemadministrationsbefehle zfs (1M)

     Beispiel 4 Deaktivieren und Aktivieren der Dateisystemkomprimierung

     Der folgende Befehl deaktiviert die Komprimierungseigenschaft für
(...)

Diese spezielle Manpage enthält 16 (!) Solcher Beispiele ... Ein großes Lob an Solaris!
(Und ich gebe zu, dass ich selbst diesen Beispielen größtenteils gefolgt bin, anstatt die gesamte Manpage für diesen Befehl zu lesen ...)


2
Der letzte Satz hebt ein Problem mit Beispielen in Handbüchern hervor. Man nimmt die Beispiele, die am besten zu seinen Bedürfnissen passen, ohne die Implikationen der jeweiligen Anwendung des Werkzeugs vollständig zu verstehen. Und später kann man einfach sagen "Ich habe es so gemacht", aber nicht wirklich warum oder was es bedeutete.
Kusalananda

6
@Kusalananda Zu meiner Verteidigung habe ich über die verschiedenen Optionen und über die Unterbefehle gelesen, die ich tatsächlich benötigt habe - nur (noch) nicht das Ganze. Es ist einfach nicht relevant für meine Anwendung ... Trotz der Gefahr des Missbrauchs, Beispiele haben einen Zweck dienen - und wenn alles , was Sie brauchen nur die grundlegendste Verwendung eines Befehls ist, das Lesen über alle Glocken und Trillerpfeifen sind kaum nötig.
Baard Kopperud

@Kusalananda Es kann auch von den Befehlen abhängen. Die meisten mir bekannten Unix- und GNU-Utils sind gut dokumentiert, aber Sie benötigen die Dokumentation, um etwas Sinnvolles zu tun. Die neueren Solaris-Befehle (insbesondere zfs) sind ziemlich natürlich gestaltet. Zum Beispiel zfs destroy pool/filesystemist grundlegende Verwendung und gut für 90% der Anwendungsfälle. Kurze Optionen wie -rfür recursivesind spezieller und müssen vor der Verwendung konsultiert werden, da sie möglicherweise unbeabsichtigte Nebenwirkungen haben.
user121391

26

Ich glaube nicht, dass es eine gute Antwort darauf gibt. Es ist eine Kultursache. Einige Handbuchseiten verwenden Beispiele. Eg man rsync. Sie können versuchen, die Kultur zu ändern, indem Sie dem Autor der Manpage schreiben und ihn bitten, einige Beispiele für die Verwendung hinzuzufügen oder (viel besser) einige Beispiele für die Verwendung selbst anzubieten. Wenn Sie einem freien Software-Autor einen Patch, insbesondere einen Dokumentations-Patch, anbieten, ist es ungefähr zehntausendmal wahrscheinlicher, das gewünschte Ergebnis zu erzielen als eine einfache Anfrage.


7

Es hängt davon ab, ob:

  • Die meisten der für Sie interessanten Programme wurden über einen bestimmten Zeitraum entwickelt, um zunächst ein Problem zu lösen und später die Lösung zu verbessern. Die Entwickler der Programme erklären, was sie für wichtig hielten (und die Dokumentation war nicht das Problem, das sie lösten).
  • für einige Programme, bevorzugen die Entwickler Probe zur Verfügung zu stellen Programme oder Skripte , die zeigen , wie ein bestimmtes Programm (oder Bibliothek) verwenden. Auch dies geschieht, um ein Problem zu lösen: Das Programm ist einfacher zu testen.

    Einige der Beispiele basieren möglicherweise auf Fehlerberichten von Benutzern und wenn short einen Platz im Handbuch findet. Ausführliche Beispiele werden in Handbüchern selten zur Verfügung gestellt, und kurze Beispiele haben das Problem, dass sie in der Regel trivial und repetitiv sind und dem Benutzer nicht so viel Einsicht bieten wie eine gut organisierte Beschreibung der Funktionsweise eines Programms.

  • In einigen Fällen finden Sie Dokumentation, die von anderen Personen bereitgestellt wird, die nicht am Entwicklungsprozess beteiligt sind. Das heißt, die Entwickler haben nur an der Überprüfung der Dokumentation teilgenommen. Diese Art von Anstrengung kann ignoriert werden.

5
"Diese Art von Anstrengung kann ignoriert werden." Ich bin mir nicht sicher, was das bedeutet.
Faheem Mitha

Die Dokumentation liefert keine nützlichen Beiträge, wenn sie nicht auf Erfahrung basiert.
Thomas Dickey

In der Tat kann eine Dokumentation, die nicht auf Erfahrung basiert, einen negativen Beitrag leisten - das heißt, sie ist einfach falsch.
Alephzero

Klar - ich habe es erwähnt, weil einige der Beispiele, an die OP zweifellos denkt, in diese Kategorie fallen (ich werde auf eine Liste in diesem Forum verzichten).
Thomas Dickey

2
@ThomasDickey. Ich stimme dieser Einschätzung überhaupt nicht zu. Die Möglichkeit, ein Dienstprogramm zu schreiben, ist nicht unbedingt mit der Möglichkeit verbunden, die API einem Endbenutzer zu erklären. T
chiggsy

6

Wenn Sie nach einer Alternative zu Manpages suchen, können Sie immer Bro-Pages ausprobieren , die einem Befehl nur verschiedene Beispiele zeigen, über die Sie dann in einer Liste von Beispielen abstimmen können, die von der Community eingereicht wurden. Der Befehl bro targibt beispielsweise Folgendes aus:Bildbeschreibung hier eingeben

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.