0 votes

Est-ce que quelqu'un d'autre a beaucoup de pages manuelles en double?

Par exemple, pour la page de manuel read, j'en ai une seule pour read(2), deux pour read(1) et deux pour read(n). Cela a entraîné quelques problèmes de performances et de synchronisation. Je pense que cela a à voir avec la gestion des dépendances par homebrew, mais je ne suis pas sûr. Par exemple, en exécutant

$ time man -k ^
makewhatis: /Library/TeX/texbin/man: Not a directory
DeRez(1)                 - décompile les ressources (OBSOLÈTE)
... dizaines de lignes de sortie
git-branch(1)            - Liste, crée ou supprime des branches
man -k ^  0.43s user 1.27s system 37% cpu 4.511 total

ce qui ne semble pas normal. Quelqu'un d'autre?

0 votes

Avez-vous défini MANPATH ? Si oui, modifierez-vous votre message avec sa valeur, et quels sont les résultats de la commande manpath.

0 votes

MANPATH n'est pas défini. Résultats de la commande : /Library/Frameworks/Python.framework/Versions/3.11/share/man‌​:/usr/local/share/ma‌​n:/usr/share/man:/Li‌​brary/TeX/texbin/man‌​:/Library/Developer/‌​CommandLineTools/SDK‌​s/MacOSX.sdk/usr/sha‌​re/man:/Library/Deve‌​loper/CommandLineToo‌​ls/usr/share/man. Il semble donc que le non-répertoire soit inclus.

0 votes

Quels types de problèmes de performances et de synchronisation rencontrez-vous ?

1voto

Marc Wilson Points 3640

Ils ne sont pas des doublons. Leur existence ne conduit à aucun problème de performance ou de synchronisation. Cela n'a rien à voir non plus avec la gestion des dépendances par Homebrew.

Ils proviennent de différentes sections du manuel. Les sections du manuel sont définies comme suit :

   1      Commandes utilisateur
   2      Appels système
   3      Fonctions de bibliothèque C
   4      Périphériques et fichiers spéciaux
   5      Formats de fichiers et conventions
   6      Jeux et autres
   7      Miscellanées
   8      Outils d'administration système et démons

Ainsi, la page de manuel pour read(1) concerne la commande read en ligne de commande. La page de manuel pour read(2) concerne l'appel système read. La page de manuel pour read(n) provient de TCL.

0 votes

Ce que je veux dire, c'est que j'ai read(1) en double et read(n) en double. Comme j'ai 2 fois le premier et 2 fois le dernier... Je pensais que c'était clair dans ma question.

0 votes

Je peux clairement voir cela quand dans emacs, en utilisant man-mode pour les parcourir.

0 votes

Avoir deux pages de manuel n'est pas un problème. Tout ce que cela signifie, c'est que dans le chemin que man a construit, il y a deux (ou plus) d'une entrée, probablement fournie par différentes installations de logiciels. Ils ne causent aucun ralentissement, ils n'occupent pas assez d'espace pour importuner.

1voto

Michael Zhou Points 167

Eh bien, à ma surprise, je rencontre le même problème. En regardant brièvement le problème-

[crystalwell:fd0] $ man -k tcsh
tcsh(1) - Coquillage C avec complétion de nom de fichier et édition de ligne de commande
tcsh(1) - Coquillage C avec complétion de nom de fichier et édition de ligne de commande

Deux répertoires se font écho l'un à l'autre-

/usr/share/man/man1

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man/man1

En y réfléchissant, je réalise que makewhatis ne peut pas écrire sa base de données sur un système de fichiers en lecture seule. En fait, makewhatis semble être désactivé sur mon système.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X