Das Folgende kann als Problemumgehung für die macOS 10.15.1-Version des Befehls apropos verwendet werden, bei der Beschwerden der Form makewhatis ausgegeben werden: / usr / lib / lib… .dylib: Kein Verzeichnis.

Erstellen Sie zuerst das Workaround-Skript:

  $ mkdir -p ~ / Problemumgehungen
$ sed -e 66s @ / usr / lib @@ / usr / bin / apropos > ~ / workarounds / apropos.macos_10.15.1
$ diff / usr / bin / apropos ~ / workarounds / apropos.macos_10.15.1
66c66
< für d in / var / cache / man $ manpath / usr / lib
--- ---.
> für d in / var / cache / man $ manpath
$ chmod + x ~ / workarounds / apropos.macos_10.15.1
 

Fügen Sie Ihrer Shell als Nächstes einen Alias ​​hinzu, um sie anzuweisen, das Workaround-Skript zu verwenden, bis eine neuere Version des kanonischen Skripts verfügbar wird.

Für Zsh können Sie den folgenden Befehl verwenden:

  $ / bin / cat <<END >> ~ / .zshrc
# Problemumgehung für fehlerhaften Befehl apropos.
alias apropos = ~ / workarounds / apropos.macos_10.15.1
ENDE
 

Verwenden Sie für andere Shells wie ksh oder bash je nach Bedarf ~ / .profile oder ~ / .bash_profile.

WWas bewirkt die Problemumgehung?

Apropos-Anforderungen (und man-k-Anforderungen) werden vom Skript / usr / bin / apropos verarbeitet. Dieses Skript sucht in allen Verzeichnissen des man-Pfads nach "whatis" -Datenbankdateien (siehe man - path ) sowie nach / var / cache / man und / usr / lib . Die Überprüfungen für / var / cache / man / whatis und / usr / lib / whatis scheinen aus historischen Gründen vorhanden zu sein, diese Dateien werden jedoch nicht aktiv in Mojave oder generiert Catalina. Viele verschiedene Leute haben im Laufe der Jahre zu den verschiedenen Varianten von Unix beigetragen, und viele von ihnen hatten unterschiedliche gute Ideen, wo verschiedene Dateitypen abgelegt werden sollten. Irgendwann entschied jemand, dass / usr / lib ein guter Ort wäre, um eine whatis-Datei abzulegen, und irgendwann dachte jemand anderes, dass / var / cache / man ein guter Ort wäre Ort. Andere meinten, der geeignete Ort wären die jeweiligen Manpage-Verzeichnisse. Verschiedene Lösungen, die zu dieser Zeit angemessen erschienen. Das apropos-Skript hat diese Speicherorte traditionell überprüft, falls eine whatis-Datei vorhanden war.

Mit dem Schritt, die Systemverzeichnisse in Catalina schreibgeschützt zu machen (ein guter Schritt), können diese Datenbankdateien nicht in Verzeichnisse wie / usr / share / man geschrieben werden. Es gibt verschiedene Möglichkeiten, wie Apple damit umgehen kann, aber für diese Version hat sich jemand entschieden, das apropos-Skript zu ändern, indem es im laufenden Betrieb Ergebnisse generiert, indem /usr/libexec/makewhatis.local für eine beliebige Manpage aufgerufen wird Verzeichnis, das keine whatis-Datei enthält.

Dieser neue apropos-Code funktioniert gut für tatsächliche Manpage-Verzeichnisse und für / var / cache / man (da er nicht vorhanden ist), schlägt jedoch für / usr / lib fehl . Die oben beschriebene Problemumgehung entfernt nur / usr / lib aus der Liste der durchsuchten Verzeichnisse.

Legen Sie als letzten Schritt in ein oder zwei Monaten eine Erinnerung fest, um zu überprüfen, ob Apple das apropos-Skript repariert hat.Wenn ja, entfernen Sie Ihre Problemumgehungen, indem Sie den Alias und das Problemumgehungsskript entfernen.

Ich bin gerade darauf gestoßen und habe mich hierher gegoogelt ...

Es sieht so aus, als würde "whatis" entweder generierte whatis-Dateien durchsuchen oder sie im laufenden Betrieb zum Standard generieren. Was wir sehen, ist die Ausgabe von "makewhatis", die unter / usr / lib ausgeführt wird.

Sie erhalten dieselben Fehler von:

  / usr / libexec / makewhatis -o / dev / fd / 1 / usr / lib
 

/ usr / lib befindet sich nicht im Manpath (Ausgabe von "man --path") - es wird explizit von "whatis" hinzugefügt, obwohl ich aus welchem ​​Grund keine Ahnung habe. Es gibt dort keine Manpages, und makewhatis erwartet eindeutig, dass alles in einem Man-Ordner ein Unterverzeichnis ist.

Wenn wir das "whatis" -Skript bearbeiten könnten, könnten wir es beheben. Dies ist jedoch nicht möglich, da / usr / bin schreibgeschützt ist.

Wenn wir ein leeres / usr / lib / whatis generieren könnten, würden die Beschwerden aufhören. Dies ist jedoch nicht möglich, da / usr / lib schreibgeschützt ist.

Es ist möglicherweise möglich, /usr/libexec/makewhatis.local zu reparieren, um diesen Unsinn zu stoppen, aber es ist schreibgeschützt.

Ich muss einige Nachforschungen anstellen, um herauszufinden, ob es eine Möglichkeit gibt, das Betriebssystem-Volume für eine Weile mit Lese- und Schreibzugriff zu versehen.

In einem verwandten Hinweis: Selbst wenn wir ein "makewhatis" zum erfolgreichen Ausführen gebracht haben, wird es / usr / lib / whatis nicht generieren, da / usr / lib nicht im Pfad des Mannes enthalten ist ... also hat es gewonnen ' t das zu beheben. Das Erstellen eines leeren / usr / lib / whatis ist wahrscheinlich die einfachste und sicherste Option, wenn wir herausfinden können, wie.

Probieren Sie dieses aus ():

1. sudo mkdir / System / Volumes / Data / usr / share / man
2. sudo / usr / libexec / makewhatis -o / System / Volumes / Daten / usr / share / man / whatis

3.   user @ host ~% cd / System / Volumes / Daten / usr / share / man /
   user @ host man% lsl
   insgesamt 384
   drwxr-xr-x 3 Wurzelrad - 96 3. November 01:33.
   drwxr-xr-x 4 Wurzelrad sunlnk 128 3. November 01:32 ..
   -rw-r - r-- 1 Wurzelrad - 160236 3. November 01:33 whatis
    

   lsl ist ein Alias für ls -laOe @ auf meinem System

ol>

Wissenswertes:

• Ich weiß nicht, wo sich diese Datei befindet (außer dass sich die Datei dort befindet) - die Datei kann nicht mit sudo find / -name "whatis" im Dateisystem gefunden werden
• Die Datei überlebt einen Neustart
• Ich habe keine Ahnung, ob diese Datei überhaupt von whatis / apropos / fish | bash | zsh Shell-Vervollständigung verwendet wird (und Ihre Probleme löst)

R bezüglich einer Lösung, die die fehlenden whatis-Dateien generiert:

Die Lösung zum Aktualisieren der "whatis" -Datenbank in / usr / share / man erfordert einen Fix von Apple. Sie müssen entweder / usr / share / man zu ihrer Liste fester Links hinzufügen (ähnlich der Implementierung für / usr / share / snmp ) oder eine statische Kopie hinzufügen der Datei whatis auf das Systemvolume.

Feste Links sind eine neue Funktion des APFS. Entwickelt, um das Zusammenführen von Lese- / Schreibvolumes mit schreibgeschützten Systemvolumes zu unterstützen. Ab der Catalina-Version werden die Kernbetriebssystemdateien auf einem schreibgeschützten Volume gespeichert, das dann über feste Links mit einem Lese- / Schreibdaten-Volume zusammengeführt wird. Unter macOS Version 10.15.1 ist / usr / share / man nur auf dem schreibgeschützten Systemvolume vorhanden. Sie können dem Datenvolumen einen Eintrag für / usr / share / man hinzufügen, indem Sie das Verzeichnis / System / Volumes / Data / usr / share / man erstellen Die Antwort von klanomath wird jedoch erst dann dem Systemverzeichnis (/ usr / share / man) zugeordnet, wenn ein entsprechender fester Link erstellt wurde.

Eine Liste der aktuellen Firmlinks finden Sie unter / usr / share / firmlinks . Die Dokumentation, die ich bisher ausgraben konnte, ist nicht klar, ob firmlinks eine Referenzdatei oder eine Konfigurationsdatei ist, aber sie sieht für mich wie eine Konfigurationsdatei aus, die gelesen und verwendet wird als Teil der Boot-Prozeduren. Angenommen, es handelt sich um eine Konfigurationsdatei, können Sie das Problem theoretisch beheben, indem Sie der Datei einen Eintrag für / usr / share / man hinzufügen.

Da / usr / share / firmlinks im schreibgeschützten System-Volume enthalten ist, können Sie es leider nicht als Benutzer oder sogar als Superuser bearbeiten.Selbst im Einzelbenutzermodus wird das Mounten der Systemvolume-Gruppe im Lese- / Schreibmodus verhindert (dh: / sbin / mount -uw / funktioniert nicht).Es kann möglich sein, das Systemvolumen als untergeordnetes Laufwerk auf einem sekundären System per R / W bereitzustellen und dann die Änderungen vorzunehmen.Aber das ist mehr Experimentierzeit, als ich bereit war, einzubringen.

Kurz gesagt, die verbesserte Sicherheit von Catalina verhindert, dass dieses Verzeichnis aktualisiert wird, bis Apple das Problem behoben hat.

Die obigen Hinweise beziehen sich auf Catalina (macOS v 10.15.1).Da es sich um eine einfache Lösung handelt, gehe ich davon aus, dass das Problem bald behoben wird.

Ich habe dieses Problem heute gerade gefunden und die folgenden Aliase in ~ / .zshrc erstellt, um die Ausgabe des Befehls zu bereinigen:

  alias apropos = "apropos 2> / dev / null"
alias whatis = "whatis 2> / dev / null"
 

Die Aliase entfernen die Fehler mithilfe der Umleitung aus der Ausgabe. Die Shell verfügt über zwei Dateideskriptoren für die Ausgabe.Die Standardausgabe ist Dateideskriptor 1 und die Standardfehlerausgabe ist Dateideskriptor 2. Die vom Skript makewhatis.local generierten Fehler werden an die Standardfehlerausgabe gesendet.

Die Umleitung der Standardfehlerausgabe erfolgt mithilfe des stderr-Dateideskriptors „2“, des Ausgabeumleitungsoperators „>“ und der Zieldatei „/ dev / null“.Die Datei / dev / null ist ein spezielles Dateisystemobjekt, das alles verwirft, was in es geschrieben wurde.Wenn die Fehler umgeleitet werden, werden nur die gewünschten Ergebnisse angezeigt.

Catalina hat den Befehl des Mannes gebrochen.

Um die Fehlermeldungen unter / bin / bash zu ignorieren, erstellen Sie einen Alias für man:

  alias man = '/ usr / bin / man 2> / dev / null'
 

Ich glaube, dies ist in MacOs 10.15.4 behoben.Vielen Dank an @minopret für den Hinweis in den Kommentaren zur ursprünglichen Frage.Das Ausführen der unveränderten Befehle whatis oder apropos führt nicht zu Fehlern.