¿Cómo evitar que la salida aleatoria de la consola rompa el terminal?

23

Hay muchas preguntas sobre SE que muestran cómo recuperarse de un terminal roto cat /dev/urandom. Para aquellos que no están familiarizados con este problema, de esto se trata:

  1. Ejecutas cat /dev/urandomo equivalente (por ejemplo, cat binary_file.dat).
  2. La basura está impresa.
  3. Eso estaría bien ... ¡excepto que su terminal continúa imprimiendo basura incluso después de que el comando haya terminado! Aquí hay una captura de pantalla de un texto mal enviado que, de hecho, es una salida de g ++:

    Captura de pantalla de ejemplo

    ¡Supongo que la gente tenía razón acerca de que los errores de C ++ a veces son demasiado crípticos!

La solución habitual es ejecutar stty sane && reset, aunque es un poco molesto ejecutarlo cada vez que esto sucede.

Por eso, en lo que quiero centrarme en esta pregunta es en la razón original por la que esto sucede y cómo evitar que el terminal se rompa después de que se emita dicho comando. No estoy en busca de soluciones, tales como tuberías de los comandos de ofender a tro xxd, porque esto requiere que saber que el programa binario / archivo salidas antes de que realmente ejecuta / imprimirlo, y hay que recordar cada vez que le sucede a los datos de salida de dichos .

Noté el mismo comportamiento en URxvt, PuTTY y el buffer de trama de Linux, así que no creo que este sea un problema específico del terminal. Mi principal sospechoso es que la salida aleatoria contiene algún código de escape ANSI que invierte la codificación de caracteres (de hecho, si ejecuta de cat /dev/urandomnuevo, es probable que rompa el terminal, lo que parece confirmar esta teoría). Si esto es correcto, ¿cuál es este código de escape? ¿Hay alguna forma estándar de desactivarlo?

rr-
fuente

Respuestas:

22

No:

  • no hay una forma estándar de "deshabilitarlo" y
  • Los detalles de la rotura son en realidad específicos del terminal, pero
  • Hay algunas características comúnmente implementadas para las que puede obtener un mal comportamiento.

Para las funciones implementadas comúnmente, busque el conjunto de caracteres alternativos de estilo VT100, que se activa mediante ^Ny ^O(activar / desactivar). Eso puede ser suprimido en algunos terminales al utilizar el modo UTF-8, pero los mismos terminales tienen una amplia oportunidad para destrozar su pantalla (hablando de pantalla de GNU, consola de Linux, la masilla aquí) con las secuencias de escape que no reconocen.

Algunas de las otras secuencias de escape, por ejemplo, dependen de las respuestas del terminal a una consulta (secuencia de escape) por parte del host. Si el host no lo espera, el resultado es basura en la pantalla.

En otros casos (vistos, por ejemplo, en dispositivos de red con secuencias de escape codificadas para la consola de Linux), otros terminales lo verán como mal codificado y parecen congelarse.

Entonces ... podría enfocarse en un solo terminal, eliminar lo que parezca una molestia (como, por ejemplo, algunos sugieren eliminar la capacidad de usar el mouse para posicionarse en los editores), y podría obtener algo que no tenga agujeros aparentes. Pero esa es solo una terminal.

Thomas Dickey
fuente
0

Si tienes el control y sabes que un comando te va a atornillar, generalmente veré la salida en algo como menos.

head -n4 /dev/urandom | less

Esto generalmente parece capturar basura e imprimirlo con una representación sensata, nunca tuve ningún problema que recuerdo después de salir con q , lo cual resalto en caso de que no esté familiarizado con dejar de fumar menos.

ThorSummoner
fuente
2
La pregunta específicamente dice que él no está buscando soluciones que requieran que usted sepa de antemano que el programa produce salida binaria.
Barmar
-1

Canalice la salida de su comando, etc. en tee -

Brandon
fuente
2
¿Cómo ayudará eso? Todavía imprimirá el resultado, pero también lo guardará en un archivo.
Barmar
¿Quizás quiso decir moreo less?
Barmar
según el OP con mi énfasis: "... después de emitir dicho comando. No estoy buscando soluciones como canalizar los comandos ofensivos"
Jeff Schaller