Ce qui suit peut être utilisé comme solution de contournement pour la version macOS 10.15.1 de la commande apropos, dans laquelle elle crache des plaintes de la forme makewhatis: / usr / lib / lib… .dylib: Pas un répertoire.

Commencez par créer le script de contournement:

  $ mkdir -p ~ / solutions de contournement
$ sed -e 66s @ / usr / lib @@ / usr / bin / apropos > ~ / contournements / apropos.macos_10.15.1
$ diff / usr / bin / apropos ~ / contournements / apropos.macos_10.15.1
66c66
< pour d dans / var / cache / man $ manpath / usr / lib
---
> pour d dans / var / cache / man $ manpath
$ chmod + x ~ / solutions de contournement / apropos.macos_10.15.1
 

Ensuite, ajoutez un alias à votre shell pour lui dire d'utiliser le script de contournement, jusqu'à ce qu'une version plus récente du script canonique soit disponible.

Pour Zsh, vous pouvez utiliser la commande suivante:

  $ / bin / cat <<END >> ~ / .zshrc
# Solution de contournement pour la commande apropos cassée.
alias apropos = ~ / contournements / apropos.macos_10.15.1
FIN
 

Pour d'autres shells tels que ksh ou bash, utilisez ~ / .profile ou ~ / .bash_profile, selon le cas.

WQue fait la solution de contournement?

Les requêtes à propos (et les requêtes man -k) sont gérées par le script / usr / bin / apropos . Ce script recherche les fichiers de base de données «whatis» dans tous les répertoires du chemin man (voir man —path ), plus / var / cache / man et / usr / lib . Les vérifications pour / var / cache / man / whatis et / usr / lib / whatis semblent être là pour des raisons historiques, mais ces fichiers ne sont pas générés activement dans Mojave ou Catalina. Beaucoup de personnes différentes ont contribué aux différentes saveurs d'Unix au fil des ans, et beaucoup d'entre elles avaient différentes bonnes idées sur l'emplacement des différents types de fichiers. À un moment donné, quelqu'un a décidé que / usr / lib serait un bon endroit pour mettre un fichier whatis, et à un autre moment, quelqu'un d'autre a pensé que / var / cache / man serait un bon endroit. D'autres ont pensé que l'emplacement approprié serait les répertoires respectifs des pages de manuel. Différentes solutions qui semblaient appropriées à l'époque. Le script apropos a traditionnellement vérifié ces emplacements au cas où un fichier whatis serait présent.

Avec le passage à la lecture seule des répertoires système sur Catalina (une bonne idée), les fichiers de base de données whatis ne peuvent pas être écrits dans des répertoires tels que / usr / share / man . Apple peut gérer cela de différentes manières, mais pour cette version, quelqu'un a décidé de modifier le script apropos en le faisant générer des résultats à la volée en appelant /usr/libexec/makewhatis.local pour n'importe quelle page de manuel répertoire qui ne contient pas de fichier whatis.

Ce nouveau code apropos fonctionne bien pour les répertoires réels des pages de manuel et pour / var / cache / man (puisqu'il n'existe pas), mais il échoue pour / usr / lib . La solution de contournement détaillée ci-dessus élimine simplement / usr / lib de la liste des répertoires recherchés.

En guise de dernière étape, fixez-vous un rappel pour un mois ou deux à partir de maintenant pour vérifier si Apple a corrigé le script apropos.Si tel est le cas, supprimez vos solutions de contournement en supprimant l'alias et le script de contournement.

Je viens de tomber sur ceci et j'ai cherché mon chemin ici ...

On dirait que "whatis" va soit greper les fichiers whatis générés, soit les générer à la volée vers la sortie standard. Ce que nous voyons est la sortie de "makewhatis" en cours d'exécution sur / usr / lib.

Vous obtiendrez les mêmes erreurs de:

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

/ usr / lib n'est pas dans le manpath (sortie de "man --path") - il est ajouté explicitement par "whatis", mais pour quelle raison je n'en ai aucune idée. Il n'y a pas de pages de manuel, et makewhatis s'attend clairement à ce que tout dans un dossier man soit un sous-répertoire.

Si nous pouvions éditer le script "whatis", nous pourrions le corriger. Mais nous ne pouvons pas, car / usr / bin est en lecture seule.

Si nous pouvions générer un / usr / lib / whatis vide, les plaintes cesseraient. Mais nous ne pouvons pas car / usr / lib est en lecture seule.

Il est peut-être possible de corriger /usr/libexec/makewhatis.local pour arrêter ce non-sens, mais il est en lecture seule.

J'ai besoin de faire quelques recherches pour voir s'il existe un moyen d'obtenir un peu de lecture-écriture sur le volume du système d'exploitation.

Sur une note connexe: même si nous avons réussi à exécuter un "makewhatis", il ne générera pas / usr / lib / whatis, car / usr / lib n'est pas dans le chemin de l'homme ... donc il a gagné ' t résoudre ce problème. Créer un / usr / lib / whatis vide est probablement l'option la plus simple et la plus sûre, si nous pouvons comprendre comment.

Essayez celui-ci ():

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

3.   utilisateur @ hôte ~% cd / System / Volumes / Data / usr / share / man /
   utilisateur @ hôte homme% lsl
   total 384
   drwxr-xr-x 3 roue racine - 96 novembre 3 01:33.
   drwxr-xr-x 4 roue racine sunlnk 128 3 novembre 01:32 ..
   -rw-r - r-- 1 roue racine - 160236 3 novembre 01:33 whatis
    

   lsl est un alias pour ls -laOe @ sur mon système

Faits amusants:

• Je ne sais pas où se trouve ce fichier (sauf que le fichier est là) - le fichier ne peut pas être trouvé avec sudo find / -name "whatis" dans le système de fichiers
• Le fichier survit à un redémarrage
• Je ne sais pas si ce fichier est utilisé par la complétion de whatis / apropos / fish | bash | zsh shell (et résout vos problèmes)

R Concernant une solution qui générerait les fichiers whatis manquants:

La solution pour mettre à jour la base de données "whatis" dans / usr / share / man nécessite un correctif d'Apple. Ils doivent soit ajouter / usr / share / man à leur liste de liens d'entreprise (similaire à l'implémentation pour / usr / share / snmp ), soit ajouter une copie statique du fichier whatis sur le volume système.

Les liens fermes sont une nouvelle fonctionnalité de l'APFS; conçu pour prendre en charge la fusion de volumes en lecture-écriture avec des volumes système en lecture seule. À partir de la version de Catalina, les fichiers du système d'exploitation de base sont conservés sur un volume en lecture seule, qui est ensuite fusionné avec un volume de données en lecture-écriture via l'utilisation de liens fermes. Sous macOS version 10.15.1, / usr / share / man n'est présent que sur le volume système en lecture seule. Vous pouvez ajouter une entrée pour / usr / share / man au volume de données en créant le répertoire / System / Volumes / Data / usr / share / man , comme démontré par réponse de klanomath, mais elle ne sera pas mappée sur le répertoire système (/ usr / share / man) tant qu’un lien d’entreprise correspondant n’a pas été créé.

Une liste des firmlinks actuels peut être trouvée dans / usr / share / firmlinks . La documentation que j'ai pu fouiller jusqu'à présent n'est pas claire quant à savoir si firmlinks est un fichier de référence, ou un fichier de configuration, mais cela me ressemble à un fichier de configuration qui est lu et utilisé dans le cadre des procédures de démarrage. En supposant qu'il s'agit d'un fichier de configuration, vous pouvez théoriquement corriger le problème en ajoutant une entrée pour / usr / share / man au fichier.

Malheureusement, puisque / usr / share / firmlinks est hébergé dans le volume système en lecture seule, vous ne pouvez pas le modifier en tant qu'utilisateur, ni même en tant que super-utilisateur.Même en mode mono-utilisateur, le montage du groupe de volumes système en mode lecture-écriture est interdit (c'est-à-dire que / sbin / mount -uw / ne fonctionne pas).Il peut être possible de monter en lecture / écriture le volume système en tant que lecteur subsidiaire sur un système secondaire, puis d'effectuer les modifications;mais c’est plus de temps d’expérimentation que je n’étais prêt à en consacrer.

En bref, la sécurité améliorée de Catalina empêche la mise à jour de ce répertoire jusqu'à ce qu'Apple corrige le problème.

Les notes ci-dessus sont relatives à Catalina (macOS v 10.15.1).Comme il s'agit d'une solution simple, je pense que le problème sera bientôt corrigé.

Je viens de trouver ce problème aujourd'hui et j'ai créé les alias suivants dans ~ / .zshrc pour nettoyer la sortie de la commande:

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

Les alias suppriment les erreurs de la sortie en utilisant la redirection. Le shell a deux descripteurs de fichier pour la sortie.La sortie standard est le descripteur de fichier 1 et la sortie d'erreur standard est le descripteur de fichier 2. Les erreurs générées par le script makewhatis.local sont envoyées à la sortie d'erreur standard.

La redirection de la sortie d'erreur standard se fait en utilisant le descripteur de fichier stderr «2», l'opérateur de redirection de sortie «>» et le fichier de destination «/ dev / null».Le fichier / dev / null est un objet de système de fichiers spécial qui supprime tout ce qui y est écrit.Avec les erreurs redirigées, seuls les résultats souhaités sont affichés.

Catalina a enfreint la commande man.

Pour ignorer les messages d'erreur sous / bin / bash , créez un alias pour man:

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

Je pense que cela est corrigé dans MacOs 10.15.4.Merci à @minopret de l'avoir signalé dans les commentaires sur la question initiale.L'exécution des commandes whatis ou apropos non modifiées n'entraîne pas d'erreurs.