La interfaz de terminal POSIX es una abstracción generalizada que comprende tanto una interfaz de programación de aplicaciones para programas como un conjunto de expectativas de comportamiento para los usuarios de una terminal , tal como se define en el estándar POSIX y la Especificación Única de Unix . Es un desarrollo histórico a partir de las interfaces de terminal de BSD versión 4 y Unix de Séptima Edición .
En los sistemas Unix, una multiplicidad de dispositivos de E/S se consideran "terminales". [1] [2] Estos incluyen:
A diferencia de sus contemporáneos mainframe y minicomputadora [ cita requerida ] , el sistema Unix original fue desarrollado únicamente para terminales tontas , y ese sigue siendo el caso hoy en día. [6] Una terminal es un dispositivo orientado a caracteres, que comprende flujos de caracteres recibidos desde y enviados al dispositivo. [6] [7] Aunque los flujos de caracteres están estructurados, incorporando caracteres de control , códigos de escape y caracteres especiales, el protocolo de E/S no está estructurado como lo estaría el protocolo de E/S de terminales inteligentes . No hay especificaciones de formato de campo. No hay transmisión en bloque de pantallas enteras (formularios de entrada) de datos de entrada.
Por el contrario, los mainframes y minicomputadoras en arquitecturas cerradas comúnmente utilizan terminales orientadas a bloques .
Las "capacidades" de un terminal comprenden varias funciones de terminal tontas que van más allá de lo que está disponible en un teletipo puro, y que los programas pueden utilizar. Comprenden (principalmente) códigos de escape que se pueden enviar o recibir del terminal. Los códigos de escape enviados al terminal realizan varias funciones que un terminal CRT (o emulador de terminal de software) es capaz de hacer y un teletipo no, como mover el cursor del terminal a posiciones en la pantalla, limpiar y desplazarse por toda o parte de la pantalla, encender y apagar dispositivos de impresión conectados, teclas de función programables, cambiar colores y atributos de visualización (como video inverso ) y configurar cadenas de título de visualización. Los códigos de escape recibidos del terminal significan cosas como tecla de función , tecla de flecha y otras pulsaciones de teclas especiales ( tecla de inicio , tecla de fin , tecla de ayuda , tecla PgUp , tecla PgDn , tecla de inserción , tecla de borrar , etc.). [8] [9]
Estas capacidades están codificadas en bases de datos que son configuradas por un administrador de sistema y a las que se accede desde programas a través de la biblioteca terminfo (que reemplaza a la antigua biblioteca termcap ), sobre la que a su vez se construyen bibliotecas como las bibliotecas curses y ncurses . Los programas de aplicación utilizan las capacidades de la terminal para proporcionar interfaces de usuario textuales con ventanas, cuadros de diálogo, botones, etiquetas, campos de entrada, menús, etc. [10] [11]
TERMet al.El conjunto particular de capacidades para el terminal que utiliza la entrada y salida de un programa (que reconoce terminales) se obtiene de la base de datos en lugar de estar integrado en programas y bibliotecas, y está controlado por la TERM variable de entorno (y, opcionalmente para las bibliotecas termcap y terminfo, las variables de entorno TERMCAPy TERMINFO, respectivamente). [10] Esta variable la establece cualquier programa de monitorización de terminal que genere los programas que luego utilizan ese terminal para su entrada y salida, o a veces de forma explícita. Por ejemplo:
TERMvariable de entorno de acuerdo con una base de datos del sistema (generalmente inittab o los archivos de configuración de los programas ttymon o launchd ) que define qué terminales locales están conectados a qué puertos seriales y qué tipos de terminales proporcionan las terminales virtuales locales o la consola del sistema local.TERMvariable de entorno inmediatamente después de iniciar sesión en el tipo correcto. (Lo más habitual es que el tipo de terminal configurado por el programa getty para la línea de acceso telefónico, que el administrador del sistema ha determinado que es la más utilizada por los usuarios de acceso telefónico con terminales remotas, coincida con el que utiliza el usuario de acceso telefónico y ese usuario no tiene necesidad de anular el tipo de terminal).TERMvariable de entorno en el mismo tipo de terminal que el cliente SSH. [12]TERMvariable de entorno para especificar el tipo de terminal que está emulando. Los terminales emulados a menudo no coinciden exactamente con el hardware de terminal real, y los emuladores de terminal tienen nombres de tipo dedicados para su uso. El programa xterm (por defecto) establece xtermcomo el tipo de terminal, por ejemplo. [13] El programa GNU Screen establece screencomo el tipo de terminal.Los terminales proporcionan funciones de control de trabajos. De manera interactiva, el usuario en el terminal puede enviar caracteres de control que suspenden el trabajo que se está ejecutando actualmente, volviendo al shell de control de trabajos interactivo que generó el trabajo, y puede ejecutar comandos que colocan trabajos en "segundo plano" o que cambian otro trabajo en segundo plano al primer plano (reanudándolo si es necesario). [14] [15]
Estrictamente hablando, en Unix un dispositivo terminal comprende el controlador de dispositivo tty subyacente , responsable del control físico del hardware del dispositivo a través de instrucciones de E/S y el manejo de solicitudes de interrupción del dispositivo para entrada y salida de caracteres, y la disciplina de línea . Una disciplina de línea es independiente del hardware del dispositivo real, y la misma disciplina de línea se puede utilizar para un dispositivo concentrador de terminal responsable de múltiples terminales de control que para un pseudoterminal. De hecho, la disciplina de línea (o, en el caso de BSD, AIX y otros sistemas, las disciplinas de línea ) son las mismas en todos los dispositivos terminales. Es la disciplina de línea la que es responsable del eco local, la edición de línea, el procesamiento de modos de entrada, el procesamiento de modos de salida y el mapeo de caracteres. Todas estas cosas son independientes del hardware real, ya que tratan con las abstracciones simples proporcionadas por los controladores de dispositivo tty: transmitir un carácter, recibir un carácter, establecer varios estados de hardware. [16] [17]
En los sistemas Unix de séptima edición , BSD y derivados, incluidos macOS y Linux , cada dispositivo terminal se puede cambiar entre múltiples disciplinas de línea. [18] En el sistema AT&T STREAMS , las disciplinas de línea son módulos STREAMS que se pueden insertar y extraer de una pila de E/S STREAMS. [19]
La interfaz de terminal POSIX se deriva de las interfaces de terminal de varios sistemas Unix.
La interfaz de terminal proporcionada por Unix 32V y Seventh Edition Unix, y también presentada por BSD versión 4 como el antiguo controlador de terminal , era simple, en gran parte orientada a los teletipos como terminales. La entrada se ingresaba una línea a la vez, y el controlador de terminal en el sistema operativo (y no los terminales mismos) proporcionaba capacidades de edición de línea simples. El núcleo mantenía un búfer en el que se realizaba la edición. Las aplicaciones que leían la entrada del terminal recibían el contenido del búfer solo cuando returnse presionaba la tecla en el terminal para finalizar la edición de línea. La tecla enviada desde el terminal al sistema borraba ("mataba") todo el contenido actual del búfer de edición y normalmente se mostraba como un símbolo ' @ ' seguido de una secuencia de nueva línea para mover la posición de impresión a una nueva línea en blanco. La tecla enviada desde la terminal al sistema borraría el último carácter del final del buffer de edición, y normalmente se mostraría como un símbolo ' # ', que los usuarios tendrían que reconocer como indicativo de un "borrado" del carácter precedente (los teletipos no son físicamente capaces de borrar caracteres una vez que han sido impresos en el papel). [20] [21] [22] [23] [18]@#
Desde un punto de vista de programación, un dispositivo terminal tenía velocidades de transmisión y recepción en baudios , caracteres de "borrado" y "eliminación" (que realizaban la edición de línea, como se explicó), caracteres de "interrupción" y "salida" (generando señales para todos los procesos para los cuales el terminal era un terminal de control), caracteres de "inicio" y "detención" (usados para el control de flujo del módem ), un carácter de "fin de archivo" (que actuaba como un retorno de carro excepto que la llamada del sistema lo descartaba del búfer read()y, por lo tanto, potencialmente causaba que se devolviera un resultado de longitud cero) y varias banderas de modo básico que determinaban si el eco local era emulado por el controlador de terminal del núcleo, si el control de flujo del módem estaba habilitado, las longitudes de varios retrasos de salida, el mapeo para el carácter de retorno de carro y los tres modos de entrada. [24]
Los tres modos de entrada fueron:
En el modo de línea, la disciplina de línea realiza todas las funciones de edición de línea y reconoce los caracteres de control de "interrupción" y "salida" y los transforma en señales enviadas a los procesos. Los programas de aplicación que leen desde la terminal reciben líneas completas, después de que el usuario haya completado la edición de línea presionando Enter. [21] [25]
El modo cbreak es uno de los dos modos de caracteres por vez. ( Stephen R. Bourne se refirió a él en broma (Bourne 1983, p. 288) como un modo "a medio cocinar" y, por lo tanto, "raro"). La disciplina de línea no realiza ninguna edición de línea, y las secuencias de control para las funciones de edición de línea se tratan como una entrada de caracteres normal. Los programas de aplicación que leen desde la terminal reciben caracteres inmediatamente, tan pronto como están disponibles en la cola de entrada para ser leídos. Sin embargo, los caracteres de control de "interrupción" y "salida", así como los caracteres de control de flujo del módem, aún se manejan de manera especial y se eliminan del flujo de entrada. [26] [27]
La interfaz programática para consultar y modificar todos estos modos y caracteres de control era la ioctl()llamada del sistema . (Esta reemplazó a las llamadas del sistema stty()y gtty()de la Sexta Edición de Unix.) [29] [30] Aunque los caracteres "borrar" y "matar" eran modificables desde sus valores predeterminados de y , durante muchos años fueron los valores predeterminados preestablecidos en los controladores de dispositivos de terminal, y en muchos sistemas Unix, que solo modificaban la configuración del dispositivo de terminal como parte del proceso de inicio de sesión, en los scripts de inicio de sesión del sistema que se ejecutaban después de que el usuario hubiera ingresado el nombre de usuario y la contraseña, cualquier error en los mensajes de inicio de sesión y contraseña tenía que corregirse utilizando los caracteres clave de edición históricos heredados de los terminales de teletipo. [23]#@
Con los Unix BSD llegaron el control de trabajos y un nuevo controlador de terminal con capacidades extendidas. [18] Estas extensiones comprendían caracteres especiales adicionales (nuevamente modificables mediante programación):
SIGTSTPLa interfaz programática para consultar y modificar todos estos modos adicionales y caracteres de control seguía siendo la ioctl()llamada al sistema, que sus creadores (Leffler et al. 1989, p. 262) describieron como una "interfaz bastante desordenada". Se mantuvo toda la funcionalidad original de Unix de la Séptima Edición y se agregó la nueva funcionalidad mediante ioctl()códigos de operación adicionales, lo que dio como resultado una interfaz programática que claramente había crecido y que presentaba cierta duplicación de funcionalidad. [31]
El Sistema III introdujo una nueva interfaz de programación que combinaba las operaciones separadas de la Séptima Edición ioctl()para obtener y establecer indicadores y para obtener y establecer caracteres de control en llamadas que usaban una termioestructura para contener tanto indicadores como caracteres de control y que podían obtenerlos en una sola operación y establecerlos en otra sola operación. También dividió algunos de los indicadores de la interfaz de la Séptima Edición en múltiples indicadores separados y agregó algunas capacidades adicionales, aunque no admitía el control de trabajos ni las mejoras del modo cocinado de 4BSD. [32] Por ejemplo, reemplazó los modos "cocinado", "cbreak" y "sin procesar" de la Séptima Edición con diferentes abstracciones. El reconocimiento de caracteres generadores de señales es independiente del modo de entrada, y solo hay dos modos de entrada: canónico y no canónico. (Esto permite un modo de entrada de terminal que no está presente en la Séptima Edición y BSD: modo canónico con la generación de señales deshabilitada).
Los sucesores del Sistema III, incluido el Sistema V , utilizaron la misma interfaz.
Uno de los principales problemas que el estándar POSIX abordó con su definición de una interfaz de terminal general fue la plétora de interfaces programáticas. Aunque en el momento de la creación del estándar el comportamiento de las terminales era bastante uniforme de un sistema a otro, ya que la mayoría de los Unix habían adoptado las nociones de disciplinas de línea y las capacidades de control de tareas de BSD, la interfaz programática con las terminales a través de la ioctl()llamada al sistema era un caos. Los distintos Unix proporcionaban ioctl()operaciones diferentes, con nombres (simbólicos) diferentes y diferentes indicadores. El código fuente portable tenía que contener una cantidad significativa de compilación condicional para dar cabida a las diferencias entre las plataformas de software, aunque todas fueran teóricamente Unix. [33]
El estándar POSIX reemplaza el ioctl()sistema por completo, con un conjunto de funciones de biblioteca (que, por supuesto, pueden implementarse en segundo plano mediante ioctl()operaciones específicas de la plataforma) con nombres y parámetros estandarizados. La termioestructura de datos de System V Unix se utilizó como plantilla para la termiosestructura de datos POSIX, cuyos campos permanecieron prácticamente inalterados, excepto que ahora se utilizaban tipos de datos alias para especificar los campos, lo que permitía que los implementadores los trasladaran fácilmente a múltiples arquitecturas de procesador, en lugar de requerir explícitamente los tipos de datos unsigned shorty charde los lenguajes de programación C y C++ (que podrían ser tamaños inconvenientes en algunas arquitecturas de procesador). [33] [34]
POSIX también introdujo soporte para el control de trabajos, con una termiosestructura que contiene caracteres de suspensión y suspensión retrasada además de los caracteres de control soportados por System III y System V. No agregó ninguna de las extensiones de modo cocinado de BSD, aunque SunOS 4.x, System V Release 4 , Solaris , HP-UX , AIX , BSD más nuevos, macOS y Linux las han implementado como extensiones a termios.
Cada proceso del sistema tiene un único terminal de control o no tiene ningún terminal de control. Un proceso hereda su terminal de control de su padre, y las únicas operaciones sobre un proceso son adquirir un terminal de control, por parte de un proceso que no tiene terminal de control, y renunciar a él, por parte de un proceso que tiene un terminal de control. [33]
No se define ninguna forma portátil de adquirir un terminal de control, ya que el método se define por implementación. El estándar define el O_NOCTTYindicador para la open()llamada al sistema , que es la forma de evitar lo que de otro modo sería la forma convencional de adquirir un terminal de control (un proceso sin terminal de control, open()un archivo de dispositivo de terminal que no sea ya el terminal de control de algún otro proceso, sin especificar el O_NOCTTYindicador [35] ), pero deja su semántica convencional opcional.
Cada proceso también es miembro de un grupo de procesos. Cada dispositivo terminal registra un grupo de procesos que se denomina su grupo de procesos en primer plano . Los grupos de procesos controlan el acceso al terminal y la entrega de señales. Las señales generadas en el terminal se envían a todos los procesos que son miembros del grupo de procesos en primer plano del terminal. read()y write()las operaciones de E/S en un terminal por parte de un proceso que no es miembro del grupo de procesos en primer plano del terminal harán que se envíen señales ( SIGTTINy SIGTTOUrespectivamente) al proceso que las invoca, y pueden hacerlo opcionalmente (respectivamente). Varias funciones de biblioteca que alteran el modo terminal tienen el mismo comportamiento que write(), excepto que siempre generan las señales, incluso si esa funcionalidad está desactivada para write()sí misma. [36] [37]
La estructura de datos utilizada por todas las llamadas a la biblioteca de terminal es la termiosestructura [38] cuya definición en lenguaje de programación C y C++ es la siguiente: [34]
struct termios { tcflag_t c_iflag ; // Modos de entrada tcflag_t c_oflag ; // Modos de salida tcflag_t c_cflag ; // Modos de control tcflag_t c_lflag ; // Modos locales cc_t c_cc [ NCCS ] ; // Caracteres de control } ; El orden de los campos dentro de la termiosestructura no está definido, y las implementaciones pueden agregar campos no estándar. [34] De hecho, las implementaciones deben agregar campos no estándar para registrar las velocidades de entrada y salida en baudios. Estos se registran en la estructura, en un formato definido por la implementación, y se accede a ellos a través de funciones de acceso, en lugar de mediante la manipulación directa de los valores de campo, como es el caso de los campos de la estructura estandarizada. [39]
Los alias de los tipos de datos tcflag_ty cc_t, así como la constante simbólica NCCSy las constantes simbólicas para los distintos indicadores de modo, los nombres de los caracteres de control y las velocidades en baudios, se definen en un encabezado estándar termios.h. (Esto no debe confundirse con el encabezado de nombre similar termio.hde System III y System V, que define una termioestructura similar y muchas constantes simbólicas con nombres similares. Esta interfaz es específica de System III y System V, y el código que la utiliza no necesariamente será transferible a otros sistemas). [40]
Los campos de la estructura son (en resumen, para más detalles véase el artículo principal [ aclaración necesaria ] ):
c_iflagc_oflagc_cflagc_lflagSIGTTOUseñal por la write()llamada del sistema [39]Las funciones de la biblioteca son (en resumen, para más detalles consulte el artículo principal [ aclaración necesaria ] ):
tcgetattr()termiosestructura [43]tcsetattr()termiosestructura, opcionalmente esperando que se vacíe la salida en cola y vaciando la entrada en cola [43]cfgetispeed()termiosestructura [44]cfgetospeed()termiosestructura [44]cfsetispeed()termiosestructura [44]cfsetospeed()termiosestructura [44]tcsendbreak()tcdrain()tcflush()tcflow()tcgetpgrp()tcsetpgrp()El c_cc[]miembro de la matriz de la termiosestructura de datos especifica todos los caracteres especiales (modificables mediante programación). Los índices de la matriz son constantes simbólicas, una para cada tipo de carácter especial, como se muestra en la tabla de la derecha. (Otras dos entradas de la matriz son relevantes para el procesamiento de entrada en modo no canónico y se analizan a continuación). [43]
Los caracteres especiales que no se pueden modificar mediante programación son el salto de línea (ASCII LF) y el retorno de carro (ASCII CR). [47]
El procesamiento de entrada determina el comportamiento de la read()llamada al sistema en un dispositivo terminal y las características de edición de línea y generación de señales de la disciplina de línea. A diferencia del caso de Unix de Séptima Edición y BSD versión 4, y al igual que el caso de System III y System V, la edición de línea opera en uno de sólo dos modos: modo canónico y modo no canónico. La diferencia básica entre ellos es cuándo, desde el punto de vista de los requisitos de bloqueo/no bloqueo de la read()llamada al sistema (especificados con el O_NONBLOCKindicador en el descriptor de archivo mediante open()o fcntl()), los datos "están disponibles para lectura". [48]
En el modo canónico, los datos se acumulan en un búfer de edición de línea y no se vuelven "disponibles para lectura" hasta que el usuario (en la terminal) finaliza la edición de línea enviando un carácter delimitador de línea . Los caracteres delimitadores de línea son caracteres especiales, y son fin de archivo , fin de línea y avance de línea (ASCII LF). Los dos primeros se pueden configurar mediante programación, mientras que el último es fijo. Los dos últimos se incluyen en el búfer de edición de línea, mientras que el primero no. [49]
En términos más estrictos, se acumulan cero o más líneas en el búfer de edición de línea, separadas por delimitadores de línea (que pueden o no descartarse una vez que read()se llega al momento de leerlos), y la edición de línea opera sobre la parte del búfer de edición de línea que sigue al último delimitador de línea (si lo hay) en el búfer. Por lo tanto, por ejemplo, el carácter de "borrado" (cualquiera que haya sido programado) borrará el último carácter en el búfer de línea solo hasta (pero sin incluir) un delimitador de línea anterior. [49]
En el modo no canónico, los datos se acumulan en un búfer (que puede ser o no el búfer de edición de línea; algunas implementaciones tienen colas separadas de "entrada procesada" y "entrada sin procesar") y se vuelven "disponibles para lectura" según los valores de dos parámetros de control de entrada, los miembros c_cc[MIN]y de la estructura de datos. Ambos son cantidades sin signo (porque se requiere que sea un alias para un tipo sin signo). El primero especifica un número mínimo de caracteres y el segundo especifica un tiempo de espera en décimas de segundo. [50] Hay cuatro posibilidades:c_cc[TIME]termioscc_t
c_cc[TIME]y c_cc[MIN]ambos son ceroread()retorna inmediatamente con cualquier dato que esté en el búfer (potencialmente retornando cero si no hay datos disponibles). [51]c_cc[TIME]es distinto de cero y c_cc[MIN]es ceroread()llamada al sistema o si se recibe un solo carácter. En otras palabras, read()espera un tiempo total máximo especificado y puede devolver cero datos, y devuelve cualquier dato tan pronto como se recibe. [51]c_cc[TIME]es cero y c_cc[MIN]no es ceroread()espera una cantidad mínima de datos (que puede ser mayor que la que el llamador está dispuesto a leer en la llamada del sistema), no devolverá datos cero y puede esperar indefinidamente. [51]c_cc[TIME]y c_cc[MIN]ambos son distintos de ceroread()espera una cantidad mínima de datos (que puede ser mayor que lo que el llamador está dispuesto a leer en la llamada del sistema), no devolverá datos cero, puede esperar indefinidamente, pero no esperará más que el tiempo de espera especificado si al menos un carácter está en el búfer para ser leído. [51]El procesamiento de salida no ha cambiado mucho con respecto a sus orígenes en System III/System V. Los indicadores de control del modo de salida determinan varias opciones: