¿Por qué los títulos de las secciones de las páginas del manual no son completamente greppables?

Esto se probó en El Capitan y en High Sierra de un colega, en la Terminal estándar (bash).

user@hostname ~ $ man ls | grep "BU"
BUGS
user@hostname ~ $ man ls | grep "BUG"
user@hostname ~ $ 
user@hostname ~ $ man ls | grep "IEEE"
     files in order to be compatible with the IEEE Std 1003.2 (``POSIX.2'')
     The ls utility conforms to IEEE Std 1003.1-2001 (``POSIX.1'').

Para aclarar: "ERRORES" es un título de sección en esa (y varias otras) páginas de manual. Para los títulos de las secciones, grepping solo parece funcionar para los primeros 2 caracteres; esto es consistente en algunos títulos de sección diferentes que probamos. Para el resto del contenido, grepparece funcionar como se esperaba.

Ingresé a una caja de Linux sin sabor a BSD (Amazon Linux) y no parece exhibir el mismo comportamiento.

¿Que está pasando aqui?

Esta es parte de la razón por la que odio al hombre BSD. Da formato al texto y ejecuta el buscapersonas incluso cuando su salida es una canalización. Y mi buscapersonas es vim, por lo que Linus no lo quiera man foo | grep bar, obtengo una tubería que no responde (y tal vez una terminal en mal estado para arrancar). :/ mandb man , que es lo que sueles ver en Linux, es más sensato.
unix.stackexchange.com/questions/371062 también es una pregunta de MacOS.

Respuestas (1)

Puede ver lo que está sucediendo si ve los códigos sin procesar dentro de una página de manual. Una forma de hacerlo es exportar la página de manual a un archivo e inspeccionar su contenido directamente:

man ls > man.ls
nano man.ls

La palabra "ERRORES" en realidad se ve así en el archivo:

B^HBU^HUG^HGS^HS

Verá que los encabezados contienen caracteres de formato, por lo que la palabra completa "ERRORES" no está presente.


Si desea acceder al contenido de texto sin formato de la página del manual, puede utilizar el comando

man -P cat <thepage>

La -Popción establece el buscapersonas en otro Unix e catignorará la información de formato, dando una salida de texto sin formato. Sin embargo, esto no parece funcionar en macOS, por lo que la salida necesita un col -bpaso manual en la canalización:

man ls | col -b | grep BUGS
¡Gracias escocés! Redirigir a un archivo y abrirlo en un editor de texto debería haber sido lo primero que intenté. Usando esa información y la información de unix.stackexchange.com/a/15866 (es decir man ls | col -b | grep "BUGS"), pude obtener lo que quería.
Holy moly, el negrita es la vieja era de TTY y máquina de escribir, escriba una letra y retroceda y vuelva a escribir la letra, sabiendo que no se alinearán perfectamente y depositarán más tinta. Tiene que haber un nroffcomando para traducir eso si es necesario grep. ¿Le importaría si lo amplío con cómo pasar el comando correcto a grofftravés man?
@Kroltan +10 y +10 para escocés también. Eso es mucho más elegante que no pensar en despellejar a este gato en particular.
@Kroltan Hmmm: para mí, man -P cat ls | grep BUGSfunciona de manera idéntica man ls | grep BUGS, ambos no devuelven nada.
@Kroltan El buscapersonas no es la parte que necesita cambiar, solo se ocupa de cuando la salida no cabe en la pantalla, por lo que viene después de que // troffhaya formateado la salida. Tampoco es suficiente eliminar los caracteres de retroceso (obtendrá "BBUUGGSS"), debe persuadir al formateador para que no los genere en primer lugar. groffnroff
Un consejo man mansugiere canalizar la salida col -bpara eliminar de forma inteligente los espacios de retroceso y, de man ls | col -b | grep BUGShecho, funciona en mi sistema (CentOS Linux). No estoy seguro si ese comando está disponible en MacOS.
¿Por qué no buscar dentro del buscapersonas predeterminado man -P "less -p BUGS" ls?
@IMSoP hmm, debe haber diferencias en el sistema entonces, lo probé en Arch y funcionó grepping para BUGS. Mi error.
Para los sistemas manuales que emplean GNU roff, existen opciones grottyque impedirán que emita secuencias de control TTY-37 o ECMA48.