Errores del comando whatis. No se puede reconstruir la base de datos con makewhatis?

Lo siguiente se puede utilizar como una solución para la versión de MacOS 10.15.1 del comando apropos, en la que arroja quejas de la forma makewhatis: /usr/lib/lib … .dylib: Not a directory.

Primero cree la solución script:

$ mkdir -p ~/workarounds
$ 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
<     for d in /var/cache/man $manpath /usr/lib
---
>     for d in /var/cache/man $manpath 
$ chmod +x ~/workarounds/apropos.macos_10.15.1

A continuación, añada un alias a su shell para indicarle que utilice la solución script, hasta que esté disponible una versión más reciente del script canónico.

Para Zsh puedes utilizar el siguiente comando:

$ /bin/cat <<END >> ~/.zshrc
# Workaround for broken apropos command.
alias apropos=~/workarounds/apropos.macos_10.15.1
END

Para otros shells como ksh o bash, utilice ~/.profile o ~/.bash_profile, según corresponda.

¿Qué hace la solución?

Las solicitudes de Apropos (y las solicitudes de man -k) son gestionadas por el /usr/bin/apropos script. Que script busca los archivos de la base de datos "whatis" en todos los directorios de la ruta man (ver man —path ), además de /var/cache/man y /usr/lib . Los controles de /var/cache/man/whatis y /usr/lib/whatis parecen estar ahí por razones históricas, sin embargo esos archivos no se generan activamente en Mojave o Catalina. Mucha gente diferente ha contribuido a los diversos sabores de Unix a lo largo de los años, y muchos de ellos tenían diferentes buenas ideas sobre dónde poner los diferentes tipos de archivos. En algún momento, alguien decidió que /usr/lib sería un buen lugar para poner un archivo whatis, y en algún otro momento alguien pensó que /var/cache/man sería un buen lugar. Otros pensaron que el lugar apropiado serían los respectivos directorios de las páginas man. Diferentes soluciones que parecieron apropiadas en su momento. El apropiado script ha comprobado tradicionalmente esas ubicaciones en caso de que un archivo whatis estuviera presente.

Con el cambio de hacer los directorios del sistema en Catalina de sólo lectura (un buen movimiento), los archivos de la base de datos whatis no se pueden escribir en directorios como /usr/share/man . Hay diferentes maneras en que Apple podría manejar eso, pero para esta versión alguien decidió alterar el apropos script haciendo que genere resultados sobre la marcha llamando a /usr/libexec/makewhatis.local para cualquier directorio de páginas de manual que no contenga un archivo whatis.

Ese nuevo código de apropiaciones funciona bien para los directorios reales de las páginas de manual, y para /var/cache/man (ya que no existe), pero falla para /usr/lib . La solución detallada anteriormente sólo elimina /usr/lib de la lista de directorios buscados.

Como último paso, ponte un recordatorio para dentro de uno o dos meses para comprobar si Apple ha arreglado el apropiado script. Si es así, elimine sus soluciones, quitando el alias y la solución script.

Acabo de encontrarme con esto y he buscado en Google el camino hasta aquí...

Parece que "whatis" va a buscar en los archivos whatis generados, o los generará sobre la marcha en la salida estándar. Lo que estamos viendo es la salida de "makewhatis" siendo ejecutado en /usr/lib.

Obtendrá los mismos errores de:

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

/usr/lib no está en el manpath (salida de "man --path") - es añadido explícitamente por "whatis", aunque por qué razón no tengo ni idea. No hay páginas man allí, y makewhatis claramente espera que todo lo que está en una carpeta man sea un subdirectorio.

Si pudiéramos editar el "whatis" script, podríamos arreglarlo. Pero no podemos, porque /usr/bin es de sólo lectura.

Si pudiéramos generar un /usr/lib/whatis vacío, se acabarían las quejas. Pero no podemos porque /usr/lib es de sólo lectura.

Podría ser posible arreglar /usr/libexec/makewhatis.local para detener esta tontería, pero es de sólo lectura.

Tengo que investigar un poco para ver si hay una forma de conseguir que el volumen del SO se monte en lectura-escritura durante un tiempo.

En una nota relacionada: Incluso si conseguimos que un "makewhatis" se ejecute con éxito, no generará /usr/lib/whatis, porque /usr/lib no está en la ruta man... así que no arreglará esto. Crear un /usr/lib/whatis vacío es probablemente la opción más fácil y segura, si podemos averiguar cómo.

Con respecto a una solución que genere los archivos whatis que faltan:

La solución para actualizar la base de datos "whatis" en /usr/share/man requiere un arreglo por parte de Apple. Tienen que añadir /usr/share/man a su lista de enlaces firmes (similar a la implementación para /usr/share/snmp ), o añadir una copia estática del whatis al volumen del sistema.

Los enlaces firmes son una nueva característica del APFS; diseñados para soportar la fusión de volúmenes de lectura-escritura con volúmenes de sistema de sólo lectura. A partir de la versión Catalina, los archivos del núcleo del sistema operativo se mantienen en un volumen de sólo lectura, que luego se fusiona con un volumen de datos de lectura-escritura mediante el uso de enlaces firmes. En la versión 10.15.1 de MacOS, /usr/share/man sólo está presente en el volumen del sistema de sólo lectura. Puede añadir una entrada para /usr/share/man al volumen de datos creando el directorio /System/Volumes/Data/usr/share/man como se demuestra en la respuesta de klanomath, pero no se mapeará en el directorio del sistema (/usr/share/man) hasta que se cree el correspondiente enlace firme.

La lista de los enlaces de empresa actuales se encuentra en /usr/share/firmlinks . La documentación que he podido desenterrar hasta ahora no es clara en cuanto a si firmlinks es un archivo de referencia, o un archivo de configuración, pero me parece que es un archivo de configuración que se lee y se utiliza como parte de los procedimientos de arranque. Asumiendo que es un archivo de configuración, entonces usted podría teóricamente corregir el problema añadiendo una entrada para /usr/share/man al archivo.

Lamentablemente, ya que /usr/share/firmlinks se aloja en el volumen de sistema de sólo lectura, no se puede editar como usuario, ni siquiera como superusuario. Incluso en modo monopuesto, se impide montar el grupo de volúmenes de sistema en modo lectura-escritura (es decir: /sbin/mount -uw / no funciona). Puede ser posible montar el volumen del sistema como una unidad subsidiaria en un sistema secundario, y luego hacer las ediciones; pero eso es más tiempo de experimentación de lo que estaba dispuesto a poner.

Así que, en resumen, la seguridad mejorada de Catalina impide actualizar ese directorio hasta que Apple solucione el problema.

Las notas anteriores son relativas a Catalina (MacOS v 10.15.1). Como se trata de una solución sencilla, espero que el problema se corrija pronto.

Acabo de encontrar este problema hoy y he creado los siguientes alias en ~/.zshrc para limpiar la salida del comando:

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

Los alias eliminan los errores de la salida utilizando la redirección. El shell tiene dos descriptores de archivo para la salida. La salida estándar es el descriptor de archivo 1 y la salida de error estándar es el descriptor de archivo 2. Los errores generados por el makewhatis.local script son enviados a la salida de error estándar.

La redirección de la salida de error estándar se realiza utilizando el descriptor de archivo stderr "2", el operador de redirección de salida ">" y el archivo de destino "/dev/null". El archivo /dev/null es un objeto especial del sistema de archivos que descarta todo lo que se escribe en él. Con los errores redirigidos sólo se muestran los resultados deseados.

Prueba este (?):

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

3. user@host ~ % cd /System/Volumes/Data/usr/share/man/ user@host man % lsl total 384 drwxr-xr-x 3 root wheel - 96 Nov 3 01:33 . drwxr-xr-x 4 root wheel sunlnk 128 Nov 3 01:32 .. -rw-r--r-- 1 root wheel - 160236 Nov 3 01:33 whatis

   lsl es un alias de ls -laOe@ en mi sistema

Datos curiosos:

• No sé dónde está este archivo (excepto que el archivo está ahí) - el archivo no se puede encontrar con sudo find / -name "whatis" en el sistema de archivos
• El archivo sobrevive a un reinicio
• No tengo ni idea de si este archivo es utilizado por whatis/apropos/fish|bash|zsh shell completion (y resuelve sus problemas)