Todos los componentes de shell comparten la misma página de manual
BUILTIN(1) BSD General Commands Manual BUILTIN(1)
NAME
builtin, !
etc.
Luego hay un pequeño texto que describe qué son los componentes integrados de shell, y luego una lista que se ve así:
Command External csh(1) sh(1)
! No No Yes
% No Yes No
Pero si lo hacemos man grep
, obtenemos secciones como
- Loco
- Historia
- Ver también
- Normas
- Descripción
etc.
¿Las construcciones de conchas no tienen su propia historia, descripción y argumentos como -A
o -r
? ¿Por qué no se proporciona eso en las páginas del manual y cómo aprendería a usarlas de manera correcta y eficiente?
command-line
osx
freebsd
man
Nombre para mostrar
fuente
fuente
Respuestas:
Porque las incorporaciones son parte del caparazón. Cualquier error o historial que tengan son errores e historial del propio shell. No son comandos independientes y no existen fuera del shell en el que están integrados.
El equivalente,
bash
al menos, es elhelp
comando. Por ejemplo:Todos los integrantes de bash tienen
help
páginas. Incluso ahelp
sí mismo:Inspirado por el
sed
script de @ mikeserv , aquí hay una pequeña función que imprimirá la sección relevante de una página man usando Perl. Agregue esta línea al archivo de inicialización de su shell (~/.bashrc
para bash):Luego, lo ejecuta dándole una página de manual y el nombre de una sección:
fuente
SHELL BUILTIN COMMANDS
sección de labash
página del manual. Sus "páginas man" sonhelp builtin_name
.man git commit
aparece una página del manual degit-commit
. Algo asíman bash if
sería maravilloso .Si bien es cierto que algunos componentes integrados de shell pueden tener una escasa presentación en un manual completo, especialmente para aquellos
bash
componentes específicos que solo es probable que use en un sistema GNU (la gente de GNU, por regla general, no creeman
y prefieren sus propiasinfo
páginas) - la gran mayoría de las utilidades POSIX - shell incorporadas o no - están muy bien representadas en la Guía del Programador POSIX.Aquí hay un extracto de la parte inferior de mi
man sh
(que probablemente tenga más de 20 páginas ...)Todos los que están allí, y otros no mencionados, como
set
,read
,break
..., bueno, no necesito nombrarlos a todos. Pero tenga(1P)
en cuenta que en la parte inferior derecha, denota la serie de manuales POSIX categoría 1, esas son lasman
páginas de las que estoy hablando.¿Puede ser que solo necesites instalar un paquete? Esto parece prometedor para un sistema Debian. Si bien
help
es útil, si puede encontrarlo, definitivamente debería obtener esaPOSIX Programmer's Guide
serie. Puede ser extremadamente útil. Y sus páginas constituyentes son muy detalladas.Aparte de eso, los componentes integrados de shell se enumeran casi siempre en una sección específica del manual de shell específico.
zsh
, por ejemplo, tiene unaman
página completa para eso (creo que totaliza 8 o 9zsh
páginas individuales , incluida lazshall
que es enorme).Por
grep
man
supuesto, puedes :... que está bastante cerca de lo que solía hacer cuando buscaba en una
man
página de shell . Perohelp
es bastante buenobash
en la mayoría de los casos.De hecho, he estado trabajando en un
sed
script para manejar este tipo de cosas recientemente. Así es como agarré la sección en la imagen de arriba. Todavía es más largo de lo que me gusta, pero está mejorando y puede ser bastante útil. En su iteración actual, extraerá de manera bastante confiable una sección de texto sensible al contexto que coincida con un encabezado de sección o subsección basado en [a] patrón [s] dado en la línea de comando. Colorea su salida e imprime en stdout.Funciona evaluando los niveles de sangría. Las líneas de entrada no en blanco generalmente se ignoran, pero cuando encuentra una línea en blanco comienza a prestar atención. Reúne líneas desde allí hasta que verifica que la secuencia actual definitivamente sangra más de lo que lo hizo su primera línea antes de que ocurra otra línea en blanco o de lo contrario deja caer el hilo y espera el siguiente espacio en blanco. Si la prueba es exitosa, intenta hacer coincidir la línea principal con sus argumentos de línea de comando.
Esto significa que un partido de patrón que coincida con:
..y..
..pero no..
..o..
Si se puede encontrar una coincidencia, comienza a imprimirse. Eliminará los espacios en blanco iniciales de la línea coincidente de todas las líneas que imprime, por lo que, sin importar el nivel de sangría, encontró que la línea en ella la imprime como si estuviera en la parte superior. Continuará imprimiendo hasta que encuentre otra línea en un nivel de sangría igual o menor que su línea coincidente, por lo que secciones enteras se capturan con solo una coincidencia de encabezado, incluidas cualquiera / todas las subsecciones, párrafos que pueden contener.
Básicamente, si le pide que coincida con un patrón, solo lo hará contra un encabezado de tema de algún tipo y coloreará e imprimirá todo el texto que encuentre dentro de la sección encabezada por su coincidencia. Nada se guarda mientras lo hace, excepto la sangría de su primera línea, por lo que puede ser muy rápido y manejar
\n
entradas separadas por línea de línea de prácticamente cualquier tamaño.Me tomó un tiempo descubrir cómo recurrir a subtítulos como el siguiente:
Pero lo resolví eventualmente.
Sin embargo, tuve que volver a trabajar todo por simplicidad. Mientras que antes tenía varios bucles pequeños que realizaban principalmente las mismas cosas de maneras ligeramente diferentes para adaptarse a su contexto, al variar sus medios de recursión, logré eliminar la duplicación de la mayoría del código. Ahora hay dos bucles: uno imprime y otro comprueba la sangría. Ambos dependen de la misma prueba: el ciclo de impresión comienza cuando pasa la prueba y el ciclo de sangría se hace cargo cuando falla o comienza en una línea en blanco.
Todo el proceso es muy rápido porque la mayoría de las veces solo
/./d
elige cualquier línea que no esté en blanco y pasa a la siguiente, incluso los resultados dezshall
llenar la pantalla al instante. Esto no ha cambiado.De todos modos, hasta ahora es muy útil. Por ejemplo,
read
lo anterior se puede hacer como:... y obtiene todo el bloque. Puede tomar cualquier patrón o lo que sea, o múltiples argumentos, aunque el primero es siempre la
man
página en la que debe buscar. Aquí hay una foto de algunos de sus resultados después de que lo hice:... ambos bloques se devuelven enteros. A menudo lo uso como:
... para lo cual es bastante útil. Además, conseguirlo lo
SYNOPS[ES]
hace realmente útil:Aquí está si quieres darle un giro; no te culparé si no lo haces.
Brevemente, el flujo de trabajo es:
\n
carácter ewline se eliminará de la salida.\n
Los caracteres ewline nunca aparecen en el espacio del patrón de entrada. Solo se pueden obtener como resultado de una edición.:print
y:indent
son bucles cerrados mutuamente dependientes y son la única forma de obtener una línea\n
electrónica.:print
El ciclo de bucle comienza si los caracteres principales de una línea son una serie de espacios en blanco seguidos de un\n
carácter de línea de hilo.:indent
El ciclo comienza en las líneas en blanco, o en las:print
líneas de ciclo que fallan#test
, pero:indent
elimina todas las\n
secuencias iniciales en blanco + ewline de su salida.:print
comience, continuará tirando de las líneas de entrada, eliminando los espacios en blanco iniciales hasta la cantidad encontrada en la primera línea de su ciclo, traduce los escapes de retroceso de sobretasa y subtrazo en escapes de terminales de color e imprime los resultados hasta que#test
falle.:indent
comience, primero verifica elh
espacio anterior para ver si hay una posible continuación de sangría (como una Subsección) , y luego continúa introduciendo la entrada siempre que#test
falle y cualquier línea que sigue a la primera continúa coincidiendo[-
. Cuando una línea después de la primera no coincide con ese patrón, se elimina, y posteriormente también lo son todas las líneas siguientes hasta la siguiente línea en blanco.#match
y#test
unir los dos bucles cerrados.#test
pasa cuando la serie principal de espacios en blanco es más corta que la serie seguida por la última línea\n
ew en una secuencia de línea.#match
antepone los ewlines\n
iniciales necesarios para comenzar un:print
ciclo a cualquiera de:indent
las secuencias de salida que conducen con una coincidencia a cualquier arg de línea de comando. Esas secuencias que no se vuelven vacías, y la línea en blanco resultante se devuelve a:indent
.fuente
manperl(){ man $1 | perl -00ne "print if /^\s*$2\b/"; }
y luegomanperl sh SYNOPSIS
omanperl sh read
:)sed 'H;$!d;g;s/\(\(\n *\)match\([^\n]*\)\2 \)\{1,\}\)*.\{,1\}/\1/g'
... probablemente eso funcione ... pero eso requiere tragar el archivo y analizarlo todo de una vez. Esto funciona en una secuencia: puede manejar entradas de cualquier tamaño siempre que las líneas no sean astronómicamente largas. Se imprime a medida que funciona, y analiza todosman
los\b
escapes de ackslash para arrancar. Peroman
es solo una aplicación única: he aplicado gran parte de ella a otros problemas también ...\n\n
lugar de,\n
pero aún puede manejar cualquier entrada de tamaño e imprime a medida que funciona. Ver "modo párrafo" aquí: perldoc.perl.org/perlrun.htmlsed
ella se puede hacer como:'/./{H;$!d' -e '};x;now work the paragraph...'
. A menudo hago eso también. Pero originalmente escribí la primera parte para ver un registro en vivo durante un tiempo ilimitado, e incluso ese comportamiento era dudoso: el búfer puede explotar bajo ciertas condiciones. Eso era solo la mitad de este tamaño, loman
hizo más difícil. Sin embargo, miréman -H
después de obtener laman
sinopsis anterior, y estoy pensando que podría ser más fácil trabajar con el HTML genérico que Groff puede imprimir en sistemas GNU. Ya estoy hasta el codomansed cmd DESCRIPTION
obtiene la sección DESCRIPTION, y todas las incluidas. Una búsqueda coincidente se imprime completa y como si su nivel de sangría fuera el primero. Incluso omite los falsos positivos al ignorar los párrafos que coinciden pero que luego no sangran más. Coincide con sus argumentos a través de los escapes de retroceso de color y no los maneja hasta que esté definitivamente listo para imprimir una línea. Todo eso es muy difícil para mí con mucha más información que una sola línea a la vez.Cada caparazón tiene su propio conjunto de componentes incorporados. Si bien hay puntos en común, cada uno tiene sus propias peculiaridades que deben documentarse.
En sistemas como Linux y FreeBSD (y OSX, que hereda de FreeBSD) donde cada shell se proporciona como un paquete separado, no hay una página de manual para los componentes integrados; en cambio, cada uno de ellos está documentado en la página de manual del shell. Por lo tanto, lea la página de manual de bash para obtener la documentación de bash
kill
incorporado, lea la página de manual de dash para la documentación de la función de dashkill
, etc. También hay una página de manual para lakill
utilidad independiente.Consulte ¿Puedo obtener páginas de manual individuales para los comandos incorporados de bash? para una
man
función que muestra la documentación interna de bash en lugar de la página de manual si el argumento es el nombre de un builtin incorporado.Existen variantes de Unix que proporcionan páginas de manual para los componentes integrados de shell; de hecho, la mayoría de las variantes comerciales lo hacen. Eso es factible porque el sistema viene con un solo shell o un conjunto de shells conocidos. La página de manual discute las diferencias entre los shells. Por ejemplo, la
fg(1)
página de manual en Solaris 10 tiene secciones parash
,ksh
ycsh
. Lafg(1)
página del manual en AIX 7.1 hace referencia a "Korn shell" y "POSIX shell", pero los discute juntos (son compatibles con exactamente las mismas características parafg
). Lafg(1)
página del manual en Tru64 5.0 discute el ksh incorporado y remite a los usuarios de csh a lacsh(1)
página del manual. SCOaparentemente viene con un solo caparazón. Puede instalar otros shells como paquetes complementarios en estos sistemas operativos; si usa un shell personalizado, debe recordar que las páginas de manual para los builtins no serán relevantes cuando use un shell no predeterminado.fuente