
Ejecuté un comando en la terminal gnome que imprimió más resultados en la terminal de lo que esperaba. Me gustaría leer el resultado completo, pero el desplazamiento del terminal se detiene antes de llegar al principio.
Entiendo que puedo cambiar la configuración del perfil del terminal para permitir el desplazamiento ilimitado o canalizar la salida a un archivo, etc. Todas estas soluciones comunes se aplican afuturosalida, sin embargo.
¿Cómo veo la salida completa del terminal de un comando que ya se ha ejecutado?
Editar: Está bien, no se puede hacer. ¡Gracias a todos!
Respuesta1
Mi experiencia es que el consenso en los comentarios es correcto: una vez que se excede el búfer del terminal, esos datos se pierden (o tan buenos como, posiblemente podrían estar en la memoria que aún no se ha sobrescrito), y debido a esto usted No se puede aumentar retroactivamente el tamaño del búfer.
Esta respuesta está en el límite entre un comentario, una respuesta y quizás una exageración para su situación. Es más bien un enfoque sugerido que puede abordar su situación, en particular el problema de no saber que necesita el registro hasta que es demasiado tarde (los problemas no causales son difíciles), pero no es una respuesta directa a su pregunta.
En cualquier caso, era demasiado largo para un comentario. No estoy enumerando explícitamente todo el código necesario para implementar este enfoque, principalmente porque hay un montón de decisiones de implementación que deben tomarse; Si necesita información más detallada, estaré encantado de proporcionársela.
Script
está lejos de ser agradable tratar con
En primer lugar, la script
utilidad se ha sugerido como una "reparación provisional" para evitar la pérdida de datos sin aumentar el tamaño del búfer (lo que tiene implicaciones de seguridad cuando se configura como ilimitado). Si alguna vez hubo una utilidad que necesitaba algo de cariño, script
es esa. Por otra parte, fue desarrollado por el equipo del kernel. Lee eso como quieras.
Con frecuencia encuentro script
que es más problemático de lo que vale (postprocesarlo para hacerlo semi-legible por humanos, etc.) y en su lugar he comenzado a usar un método simplificado para registrar stdout, stdin y/o stderr. En cierto sentido, esto es recrear un script, pero con control total en lugar de estar a merced de la configuración de registro codificada script
.
Este enfoque podría integrarse de manera relativamente fluida en sus sesiones de shell y, en los raros casos en que desbordó el búfer de la terminal, tendrá un archivo temporal con ese contenido. Para mantener el registro "limpio", hay algunos pasos de limpieza que deberá seguir. Además, existirán de forma predeterminada los mismos problemas de seguridad (registro de todas las salidas del terminal); Sin embargo, existe un método sencillo para cifrar los registros.
Hay 3 pasos básicos:
- Configure la redirección para dividir stdout (y stderr si lo desea) en un archivo y en la terminal. Mantuve este ejemplo simple y no estoy dirigiendo stdin o stderr al archivo; sin embargo, si comprende el ejemplo de redirección stdout, el resto es trivial.
- Configure .bashrc para que este registro comience cada vez que se abra un shell.
- Cuando se cierra un shell determinado, use el bash incorporado
TRAP
para llamar al código de usuario que finalizará el registro de la sesión (puede eliminar el archivo, archivarlo, etc.)
Con este enfoque, tendrá efectivamente una red de seguridad invisible que le permitirá ver el historial completo de una sesión de shell determinada (según lo que redirija; nuevamente, para simplificar las cosas, solo muestro la salida estándar); cuando no lo necesitas ni siquiera deberías saber que está ahí.
Detalles
1. Configurar la redirección
El siguiente fragmento de código creará un descriptor de archivo 3, que apunta a un archivo de registro. stdout se redirige a 3 y, al usar tee
, dividimos esa secuencia nuevamente en la terminal (equivalente a stdout). Puede agregar trivialmente stderr al mismo archivo de comando/registro, canalizarlo a un archivo diferente o dejarlo como está (sin registrar).
logFile=$(mktemp -u)
exec 3>&1 1> >(tee $logFile >&3)
Descubrirá que este archivo de registro es mucho más limpio que el generado por el script; no almacena retrocesos, avances de línea ni otros caracteres especiales que frecuentemente no se desean.
Tenga en cuenta que si desea cifrar el archivo de registro, puede hacerlo con bastante facilidad agregando una etapa de tubería adicional después del comando tee a través deabresl.
2. Automatizar la generación de registros
En .bashrc agregue el mismo código que el anterior. Cada vez que se crea un nuevo shell, se creará un archivo de registro específico para esa sesión.
export logFile=$(mktemp -u)
exec 3>&1 1> >(tee $logFile >&3)
echo "Current session is being logged in $logFile"
3. Cerrar automáticamente el registro cuando se cierra Shell
Si desea que el archivo de registro se elimine cuando finalice la sesión, puede usar la función incorporada de bash trap
para detectar que la sesión está finalizando y llamar a una función para abordar el archivo de registro, por ejemplo (también en .bashrc).
trap closeLog EXIT
closeLog () {
rm -f "$logFile" >/dev/null 2>&1
}
La limpieza del registro de sesiones se puede realizar de varias maneras diferentes. Este enfoque se llamará cuando el shell se cierre atrapando la señal de "salida". En este punto, puede eliminar el archivo de registro, moverlo, cambiarle el nombre o cualquier otra cosa para limpiarlo. También podría limpiar los archivos de registro mediante un trabajo cron en lugar de mediante una TRAP (si se utiliza este enfoque, sugeriría una tarea de limpieza periódica si aún no tiene una configurada para el directorio /tmp; como si el shell bash falla y la trampa EXIT no se activará).
Nota sobre el manejo de subcapas
Se desarrollará una situación interesante con las subcapas. Si se abre un nuevo shell interactivo encima de uno existente, se creará un nuevo registro y todo debería funcionar bien. Cuando se sale de ese shell (volviendo al padre), se reanudará el inicio de sesión en ese archivo. Si desea abordar esto de manera más limpia, tal vez incluso manteniendo un registro común para subcapas (interactivas o no), deberá detectar (en .bashrc) que se encuentra en una subcapa anidada y redirigir al archivo de registro principal en lugar de creando uno nuevo. También deberá verificar si se encuentra en una subcapa para que su llamada 'trampa' no borre el archivo de registro principal al salir. Puede obtener el nivel de shell anidado desde la variable ambiental de bash SHLVL, que almacena la "profundidad" de su pila de shell.
Nota sobre cómo mantener su registro "limpio":
Si redirige stdin al archivo de registro, terminará con muchos de los mismos artefactos no deseados que genera la utilidad de secuencia de comandos. Esto se puede solucionar agregando una etapa de filtro (por ejemplo, sed/grep) entre la redirección y el archivo. Simplemente cree una expresión regular que elimine todo lo que no desee que se registre. Limpiarlo por completo requeriría un procesamiento bastante profundo (tal vez almacenar en un búfer cada nueva línea antes de escribir en el archivo, limpiarlo y luego escribirlo). De lo contrario, será difícil saber cuándo un retroceso es "basura" o es intencionado.
Respuesta2
La forma tradicional era utilizar PuTTY y conservar miles de líneas. También hay pantalla, ya que no muchos usuarios de Linux (o locales) usan PuTTY.
Ahora que Windows tiene ssh en la línea de comando, está cayendo en desuso.