Dokumentation schreibt sich nicht von selbst. Das etablierte Werkzeug Help2man erspart Ihnen jedoch eine Menge der oft ungeliebten Arbeit.
Seit langer Zeit setzt das GNU-Projekt bei den Handbüchern von Befehlszeilenprogrammen auf das Texinfo-Format. Das konkurrierende Groff-Textformat kommt insbesondere bei Debian bevorzugt zum Einsatz und ist – nicht zuletzt wegen Debians zahlreicher Ableger – das wohl am weitesten verbreitete Format für Dokumentation von Programmen für die Befehlszeile.
Beide Varianten erschließen sich nicht gerade eben schnell, bedingt durch zahlreiche Optionen und eine über Jahrzehnte gewachsene, bisweilen regelrecht verklumpte Syntax. Ein von einem Debian-Entwickler betreutes Tool namens Help2man [1] hilft aber dabei, Programme dennoch mit einer vernünftig formatierten Hilfeseite auszuliefern.
Zusätzlicher Aufwand entfällt dabei erfreulicherweise weitestgehend. Sofern der Aufruf des Programms, das Sie dokumentieren möchten, mit den Parametern --help und --version beziehungsweise deren Kurzformen -h und -v brauchbare Ergebnisse liefert, steht im Prinzip schon alles Nötige bereit.
Kombinieren Sie nun Help2man mit dem entsprechenden Programmaufruf (Listing 1, erste Zeile), baut es aus den Ausgaben mit den zwei genannten Argumenten die Dokumentation und schreibt sie in die Standardausgabe (Abbildung 1). Mit der Option -o leiten Sie die Ausgabe in eine Datei um (Listing 1, zweite Zeile). Kommen statt der üblichen --help und --version andere Schalter für Hilfe und Versionsnummer zum Einsatz, übergeben Sie diese einfach mit -h und -v an Help2man (Listing 1, letzte Zeile).
Listing 1
$ help2man /usr/bin/help2man $ help2man /usr/bin/help2man -o ~/help2man.1 $ help2man /usr/bin/foo -h --help-all -v --release -o ~/foo.1
Die Überschriften für die Abschnitte und sonstigen Bestandteile bringt Help2man dabei selbst mit und ordnet in der Regel alles korrekt ein. Das setzt allerdings voraus, dass Ihr Programm wenigstens den elementaren Richtlinien des GNU-Projekts folgt [2]. Dazu gehören mindestens eine Mail-Adresse zum Melden von Fehlern und die URL zur Webseite des Projekts.
Details
Das Programm kann wesentlich mehr, als nur die Ausgaben eines anderen Programms in ein anderes Format zu bringen. Möglicherweise wollen Sie in einer Handbuchseite mehr unterbringen als das, was die erwähnten Optionen beim Aufruf hergeben – sei es, um die Ausgabe von --help nicht zu überfrachten oder einfach, um Benutzern im Handbuch ausführlicher Auskunft zu geben. Dazu fügen Sie ganz einfach externe Texte ein. Alles, was Sie sonst noch für wichtig halten, stellen Sie einfach in einer Textdatei mit der Endung .h2m bereit und übergeben den Dateinamen als Argument mit dem Schalter --include an Help2man.
Die simple Textdatei enthält als Überschrift den (englischsprachigen) Namen der Abschnitte in Großbuchstaben, so wie Sie ihn üblicherweise in einer Manpage finden. Danach folgt der Text, den Sie im entsprechenden Abschnitt einfügen wollen (Listing 2, oben). Texte für die Abschnitte NAME und SYNOPSIS hängt Help2man allerdings nicht dort an, sondern ersetzt damit den ursprünglichen Text.
Listing 2
[DESCRIPTION] Be careful when using help2man unless you know what you do. /help option string/ Be careful when using help2man unless you know what you do.
Möchten Sie, dass der Text woanders landet, geben Sie mit einem kurzen Auszug aus dem Originaltext des Handbuchs denjenigen Absatz an, nach dem Sie den zusätzlichen Text einschieben möchten. Dazu setzen Sie dieses Textstück einfach zwischen zwei Schrägstriche (Listing 2, unten). Mit ein wenig Perl-Syntax steuern Sie über reguläre Ausdrücke die Position und Art der Einfügung noch präziser. Näheres dazu beschreibt die Manpage zu perlre [1].
Das Texinfo-Format beschränkt sich im Wesentlichen auf den harten Kern der GNU-Projekte und fand bislang anderweitig wenig Anklang. Sofern Ihr eigenes Projekt also keine entsprechenden Dateien mitbringt, sollten Sie den Absatz deaktivieren, der standardmäßig auf das Texinfo-Handbuch verlinkt. Mit dem Schalter -N erledigt Help2man das für Sie. Gibt es doch ein Texinfo-Handbuch, aber unter einem anderen Namen, geben Sie diesen mit -p an.
Zu guter Letzt hat es sich bewährt, die Option --no-discard-stderr mit anzugeben. Unter Umständen landen nämlich Teile der für Help2man wichtigen Infos im Fehlerkanal der Standardausgabe. So retten Sie diese Ausgaben des Programms und führen sie Help2man zu.
Übersetzungen
Lokalisierte Manpages sind bei Programmen für die Kommandozeile längst nicht so weit verbreitet wie bei Handbüchern für GUI-Software. Das Projekt Manpages-de [3] kümmert sich zwar sehr intensiv um die deutschsprachige Lokalisierung, doch als externes Projekt außerhalb der Upstream-Entwicklung der einzelnen Programme kann es hinsichtlich der Aktualität aber nicht immer mithalten. Dabei könnte alles so einfach sein: Bei Bedarf liefert Help2man ohne manuellen Eingriff eines Übersetzers lokalisierte Versionen aus, wenn auch bei manchen Systemen mit Einschränkungen (siehe Kasten “Die Erben von Red Hat”).
Die Erben von Red Hat
Vor langer Zeit befanden die Red-Hat-Entwickler, die Vorgehensweise von Help2man, mit LD_PRELOAD eine Programmbibliothek zum Zugriff auf lokal installierte Übersetzungen zu laden, stelle ein Sicherheitsrisiko dar. Noch heute halten Red Hat und Fedora daran fest und deaktivieren den Schalter -L. Eine diesbezügliche Nachfrage vor einiger Zeit im Bugzilla löste kein erneutes Nachdenken darüber aus [5]. Auch die im Laufe der Jahrzehnte geforkten Red-Hat-Ableger schleppen das Problem mit sich herum. Im Wesentlichen betrifft das RPM-basierte Systeme wie OpenSuse, Mageia oder PCLinuxOS. In dieser Sphäre hat nur ALT Linux die Funktion aktiviert [6].
Ob der Schalter -L auf einer Distribution tatsächlich schaltet, prüfen Sie anhand der Liste der Abhängigkeiten von Help2man: Taucht dort das Perl-Modul Locale::gettext nicht auf, funktioniert das automatische Erzeugen der Übersetzungen nicht. In der Praxis heißt das, dass Sie in Ihrem Projekt Help2man idealerweise schon vor dem Erzeugen des zu veröffentlichenden Tarballs aufrufen sollten, damit die übersetzten Versionen schon vorliegen und nur noch ins Zielsystem kopiert werden müssen. Lagern Sie den Aufruf in die Downstream-Installationsroutine aus, zum Beispiel in den Autotools-Stack, gehen die Nutzer von Red Hat und Konsorten bei lokalisierten Manpages leer aus.
Die ansonsten so sicherheitsbewussten Debian-Entwickler dagegen scheinen sich an dieser Eigenart von Help2man nicht zu stoßen. Und sogar das Fedora-Projekt selbst führt das Festhalten an der vor Jahrzehnten getroffenen Entscheidung ad absurdum: Beim Bau des Binärpakets von Help2man kommt sehr wohl der eingebaute Mechanismus zum Erstellen der übersetzten Handbuchseiten zum Einsatz, ohne dass es jemanden stört.
Eine solche Lokalisierung setzt voraus, dass für Help2man selbst eine Übersetzung in die Zielsprache existiert [4] und dass die für die Parameter -h und -v relevanten Ausgaben eines Programms bereits übersetzt vorliegen. Letzteres wäre zwar nicht zwingend notwendig, aber dennoch wenig zielführend. Zumindest stellt das sicher, dass eine lückenhafte oder verwaiste Übersetzung Ihres Programms das Erzeugen der Manpage nicht zum Scheitern bringt (Abbildung 2).

Abbildung 2: Eine nicht vorhandene Übersetzung Ihres Programms sorgt nicht dafür, dass Help2man beim Erzeugen der übersetzten Version strauchelt.
Mit dem Schalter -L de (Langfassung: --locale=de) weisen Sie das Programm an, die deutschsprachige Version gleich mitzuliefern. Ebenso verfahren Sie gegebenenfalls mit anderen verfügbaren Sprachen. Dabei müssen Sie Sonderversionen wie de_DE oder es_MX als solche angeben, sofern es eine Basisversion de oder es gibt.
Fazit
Mit dem Gespann aus Help2man und Doclifter [7] (siehe Kasten “Stresstest”) erzielen Sie schnell ordentliche Ergebnisse mit vergleichsweise wenig Aufwand. Ein Allheilmittel stellt das Tool dennoch nicht dar, weswegen sich speziell in den Ökosystemen von Skriptsprachen wie Perl oder Python eigene Systeme für die Dokumentation etabliert haben.
Stresstest
Möchten Sie sichergehen, dass die Ausgabe von Help2man nicht nur optisch korrekt ausfällt, sondern auch die Groff-Syntax über alle Zweifel erhaben ist, greifen Sie zum Tool Doclifter. Es dient eigentlich zum Umwandeln von Code in XML, eignet sich aber dank sehr ausführlicher Fehlerausgabe und sorgfältiger Arbeitsweise auch hervorragend zum Prüfen von Handbuchseiten.
Wie bei Programmen für die Befehlszeile üblich, sorgt die Option -v dafür, dass das Programm ausführlich Auskunft über sein Tun gibt. Mit dem Schalter -vv gerät die Ausgabe recht unübersichtlich, weil er selbst kleinste Schritte beim Verarbeiten protokolliert.
Der Aufruf von Doclifter mit dem Dateinamen als Argument führt im Idealfall ohne Nörgeln zu einer XML-Datei gleichen Namens, an die die Software einfach die Endung .xml anhängt. Doch schon eine lokalisierte Manpage sorgt dafür, dass die Software ins Straucheln gerät (Abbildung 3).
Die Option -w, die Sie mehrmals angeben dürfen, dient dazu, die Portabilität genau zu prüfen. Dabei treten trotz oberflächlich betrachtet fehlerfreier Syntax oft interessante Eigentümlichkeiten zutage. Um die Manpage gegen alles zu wappnen, was beim Anzeigen und Weiterverarbeiten auf diversen Plattformen unter Umständen schiefgehen kann, sollten Sie der Ursache der Meldungen nachgehen.
Kein Prüfer ohne Oberprüfer: Doclifter hat ein Skript namens Manlifter mit an Bord, das im System nach Manpages sucht, diese in XML umwandelt und die Dateien im Verzeichnis xmlman/ im aktuellen Ordner unter Beibehalten der ursprünglichen Struktur der Ordner ablegt. Die im selben Ordner gespeicherte Protokolldatei hilft beim Aufspüren von Fehlern.
Mit dem Schalter -h erzeugen Sie gleich HTML-Versionen, jedoch ohne formatierte Hyperlinks, was eine Nutzung im Webbrowser erschwert. Eine weitere Chance zum visuellen Aufspüren von Unstimmigkeiten bietet die Anzeige im Gnome-Hilfebrowser Yelp. Im Terminal rufen Sie yelp mit dem Namen der XML-Datei auf und verifizieren so die Struktur und die richtige Zuordnung von Querverweisen und Hyperlinks (Abbildung 4).
Glossar
-
Groff-Textformat
-
Die Wurzeln der Syntax für Manpages reichen bis in die späten 1960er-Jahre zurück, zu den Wurzeln von Unix. Sie erfuhr seither zahlreiche Veränderungen, Erweiterungen und Abwandlungen wie Nroff oder Troff. Auf Linux-Systemen ist Groff am weitesten verbreitet. Die üblichen Programme zum Anzeigen und Konverter verstehen sich oft außerdem auf das bei BSD-Derivaten vorherrschende Mdoc.
Infos
-
Help2man-Webseite: https://www.gnu.org/software/help2man/
-
GNU-Richtlinien für Hilfetexte: https://www.gnu.org/prep/standards/standards.html#g_t_002d_002dhelp
-
Deutsche Handbuchseiten: https://salsa.debian.org/manpages-de-team/manpages-de
-
Übersetzungen für Help2man: http://translationproject.org/domain/help2man.html
-
Help2man in ALT Linux: http://www.sisyphus.ru/en/srpm/Sisyphus/help2man/spec
-
Bugreport im Red-Hat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1048015
-
Doclifter: http://www.catb.org/esr/doclifter/









Hallo zusammen,
in diesem Umfeld sollte das Engagement für quelloffene Software auch durch viele Unternehmen und Organisationen stärker gefördert werden.
Insbesondere da die Fernsehanstalten mit versteckten oder sichtbaren Kameras in u.a. Fernsehgeräten die Bevölkerung wie in “Big Bang Theorie” oder “Der Prinz von Bel Air” überwachen. Das soll für alle dann wohl wie bei den Borg aus “Star Trek: Der Erste Kontakt” oder der “Truman Show” werden.
Also besser auf Fernseher usw. verzichten.
Selbst die Bundesnetzagentur warnt schon seit Jahren davor.
Bundesnetzagentur sagt verbotenen Spionagekameras den Kampf an
Webseite:
http://www.bundesnetzagentur.de
Abgesehen von der Tatsache, dass dieser recht wirre Kommentar rein gar nichts mit dem Artikel zu tun hat, handelt es sich hier um ein klassisches Beispiel für Fake News.
Tatsächlich warnt die Bundesnetzagentur keineswegs vor verwanzten TV-Geräten, sondern vor USB-Kameras, die als Gegenstände des täglichen Gebrauchs getarnt sind, wie Kugelschreiber, Uhren, Rauchmelder, Lampen oder Ähnliches. Den Originaltext finden Sie hier:
https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilungen/DE/2016/160425_cam.html
Wir lassen den Kommentar hier trotzdem stehen, weil uns die Löschung von Beiträgen widerstrebt, solange sie keine justiziablen oder kommerziellen Inhalte haben.
Die Redaktion