Wer an Unix-artige Systeme gewöhnt ist, neigt häufig dazu das Vorhandensein von Manpages einfach vorauszusetzen. Fehlen Manpages fällt das nicht immer gleich auf, aber wenn es auffällt dann meist auf unangenehme Art und Weise, nämlich dann wenn die Manpages gerade gebraucht werden. Manchmal fehlt eine Manpage aber auch gar nicht, sondern wird nur einfach vom System nicht gefunden, das ist dann besonders ärgerlich.
Ich hatte das Problem neulich mal wieder und da ich mich schon öfters darüber geärgert habe, bin ich diesmal der Sache auf den Grund gegangen. Bei Unix kann man sich häufig Ärger ersparen, wenn man den Dingen auf den Grund geht, da die es für sehr viele Probleme schon Lösungen gibt. Wie arbeitet also das Manpage-Subsystem?
Zunächst einmal gibt es analog zur Umgebungsvariable PATH die recht bekannte Variable MANPATH, mit der sich das Manpage-Subsystem sagen läßt, in welchen Verzeichnissen es nach Manpages suchen soll. In einem aktuellen RHEL/CentOS/Fedora glänzt diese Umgebungsvariable aber zunächst durch Abwesenheit. Natürlich kann sie an geeigneter Stelle definiert werden, etwa in .bash_login oder ähnlichen Dateien, aber warum fehlt sie von vornherein und warum werden trotzdem Manpages gefunden?
Das Manpage-Subsystem sucht selbständig einem bestimmen Schema entsprechend nach Manpages. Wird z.B. die Manpage zu einem Programm aufgerufen, das in /usr/local/bin/ liegt, dann wird zuerst in /usr/local/man/ nach der passenden Manpage gesucht. Die Variable MANPATH wird erst nötig, wenn die Manpage zu einem Programm oder einer Datei nicht an einem Ort liegt der in dieser Weise relativ zum Ort der Datei bzw. des Programms ist.
Ein Beispiel aus unserer täglichen Praxis: Nach der Installation von qmail genügt es /var/qmail/bin der Umgebungsvariable PATH hinzuzufügen, die Manpages in /var/qmail/man werden dann automatisch gefunden.
Nun ist aber genau diese relative Lage nicht durchzuhalten, wenn im Dateisystem eine grundlegende Ordnung eingehalten werden soll, wie etwa vom Filesystem Hierarchy Standard vorgeben. Denn es müßte zu jedem Ordner der Programme, Bibliotheken oder Konfigurationsdateien enthält einen Order mit den Manpages an der entsprechenden relativen Position dazu geben. Das Ergebnis wären sehr viele Ordner mit Manpages, die sich über das gesamte System verteilen. Sie alle zu durchsuchen würde relativ lange dauern (auch wenn es auf aktuellen Systemen wohl trotzdem kaum auffallen würde) und wäre reine Resourcenverschwendung.
Hier kommt nun die Datei /etc/man.config ins Spiel. Hier werden zunächst Standard-Pfade an denen viele Manpages abgelegt sind definiert, z.B. MANPATH /usr/share/man. Darüber hinaus können hier auch Abweichungen von dem oben beschriebenen relativen Pfaden definiert werden, sogenannte Mappings. Das Statement MANPATH_MAP /usr/bin /usr/share/man vermittelt dem Manpage-Subsystem, daß es für Programme in /usr/bin/ die Manpages nicht in /usr/man/ suchen braucht, sondern direkt in /usr/share/man/ suchen kann.
Wer viel Software aus den Quellen selbst übersetzt oder sich eigene RPMs baut oder selber Software schreibt, sieht sich vielleicht hin und wieder mit der Frage konfrontiert, wohin Manpages installiert werden sollen. Hier lohnt es sich den einen oder anderen Gedanken auf diese Zusammenhänge zu verwenden, statt immer wieder das Rad neuzuerfinden oder die Aufgabe dafür zu sorgen daß die Manpages auch gefunden werden einfach den Administratoren und Usern zu überlassen. Natürlich fällt auf aktuellen Computern die geringe Performance-Einbuße durch weit verstreute Manpages und Programme nicht mehr auf, diese Überlegungen können also vernachlässigt werden. Bei Embedded-Systemen sieht das natürlich schon wieder anders aus. Und vielleicht legt die eine oder der andere so wie ich auch Wert auf die Eleganz einer guten Lösung.