¿Qué tipo de terminal admitir si se implementa un emulador de terminal?

Cerrado . Esta pregunta está basada en opiniones. Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que pueda responderse con hechos y citas editando esta publicación.

Cerrado hace 4 años.

Mejorar esta pregunta

Escuché que VT100 es el estándar de facto. ¿Significa que si solo puedo admitir VT100 y luego mi terminal puede funcionar para las aplicaciones de línea de comandos existentes sin grandes problemas? Si no, ¿cómo asegurarse de que la terminal sea práctica? ¿Hay alguna referencia que pueda ayudar a alcanzar este objetivo?

Respuesta aceptada:

Estás a punto de sobrecalentar a Thomas Dickey.

Ignora el samizdat que circula desde hace años sobre los terminales VT10x. Mucho de esto está mal. El DEC VT100, VT101 y VT102 implementaron un conjunto muy específico de funciones, que uno puede aprender leyendo su doco.

Eso es no lo que la gente que anda dando vueltas incorrectamente con los términos vt100 y vt102 en realidad significa, sin embargo. A menudo, de lo que hablan es de una emulación de terminal que hace mucho más de lo que hizo un VT10x real, así como mucho menos . Un DEC VT102 real tenía una impresora en serie adjunta y secuencias de control para acceder a ella, por ejemplo. Además, no tienen muchas de las secuencias de control de emuladores de terminales posteriores y terminales reales que la gente atribuye erróneamente a "vt102". No tenía concepto de cambios de color SGR, por ejemplo.

Tienes dos opciones básicas:

• Implemente algo que sea compatible con un tipo de terminal existente que esté definido en las bases de datos termcap/terminfo. Si hace esto, debe hacerlo correctamente, copiando exactamente todo el comportamiento descrito del tipo de terminal existente. (El emulador de terminal del conjunto de herramientas nosh hace esto, emulando en Linux el linux tipo de terminales. Tiene que copiar el linux codificaciones de teclas de funciones y teclas extendidas extravagantes y limitadas del tipo de terminal).
• Implemente su propio tipo de terminal, cuyo comportamiento está diseñado por usted, que luego debe incluir en la base de datos termcap/terminfo. El emulador de terminal PuTTY, estrictamente hablando, hace esto. La descripción terminfo correcta es putty , putty-256color , o putty-sco .

Para el primero, lo que es estándar es irrelevante, ya que debe copiar el comportamiento descrito sin importar cuán no estándar sea. Para esto último, no busque estándares de facto. Mire el real estándares, algunos de los cuales existen desde 1976.

• ECMA-48 (publicado por primera vez en 1976 y posteriormente adoptado como norma ISO/IEC, ISO/IEC 6429) describe:
  • Códigos de control C0,
  • Códigos de control C1 (que son poco conocidos pero se ocupan de varias cosas útiles, como configurar/borrar tabulaciones e índice de avance/retroceso)
  • Alias ​​de 7 bits para todos los códigos de control C1 (por ejemplo, ESC [ es un alias de 7 bits para el real carácter de control de 8 bits U+009B),
  • secuencias de control introducidas por CSI (para las cuales hay una sintaxis general en el estándar que muchos analizadores de secuencias de control escritos en samizdat se equivocan),
  • y muchas otras cosas.
• ISO/IEC 2022 describe el cambio entre conjuntos de caracteres de 7 bits. Si va a implementar la capacidad UTF-8 desde el principio, es mejor ignorar ISO/IEC 2022 por completo, como Markus Kuhn y los inventores de mosh te lo diré.
• ISO/IEC 8613-6 (publicado en 1989 y revisado en 1994) describe extensiones de ECMA-48 para secuencias de control SGR de color, tanto selección de "color indexado" de una paleta como RGB de "color directo". (Ambos color directo y color indexado se definen en ISO/IEC 8613-2. Probablemente conocerá a este último por el nombre samizdat de "256 colores".)

  Nota importante: Casi todas las implementaciones implementan este estándar incorrectamente, porque trabajaron desde samizdat (o simplemente se copiaron entre sí) en lugar del estándar real. El estándar dice en §13.1.8 usar dos puntos (: , “3/10”) como separador de subparámetros; casi todas las implementaciones utilizan erróneamente punto y coma (; ), introduciendo una ambigüedad de análisis. Muchos softwares han acomodado este error.

Relacionado:¿Qué indica este proceso STAT?

Lecturas adicionales

• Funciones de control para conjuntos de caracteres codificados . ECMA-48. 5ª edición. 1991. ECMA Internacional.
• Tecnología de la información — Arquitectura de documento abierto (ODA) y formato de intercambio:Estructuras de documentos . T.412. Unión Internacional de Telecomunicaciones.
• Tecnología de la información:arquitectura de documentos abiertos (ODA) y formato de intercambio:arquitecturas de contenido de caracteres . T.416. Unión Internacional de Telecomunicaciones.
• Tecnología de la información:arquitectura de documentos abiertos (ODA) y formato de intercambio:arquitecturas de contenido de caracteres . ISO/CEI 8613-6:1994. Organización Internacional de Normalización.
• Markus Kuhn (2009). "¿Cuáles son los problemas relacionados con los emuladores de terminal UTF-8?". Preguntas frecuentes sobre UTF-8 y Unicode para Unix/Linux .
• Keith Winstein, Anders Kaseorg, et al. (2012). “Escapes con bloqueo ISO 2022“. información técnica de mosh .
• Manual de referencia del programador VT420 . EK-VT420-RM-002. Febrero de 1992. Digital.
• Información del programador del terminal de video VT520/VT525 . EK-VT520-RM. Julio de 1994. Digital.
• Thomas E. Dickey (1997). “¿Qué es un VT220?”. Preguntas frecuentes sobre xterm . isla-invisible.