Interfaz de terminal POSIX

En los sistemas Unix, se considera que múltiples dispositivos de E/S son "terminales". ^{[ 1 ] [ 2 ]} Estos incluyen:

• dispositivos serie conectados por un puerto serie como impresoras / teleimpresoras , teletipos , módems que admiten terminales remotas a través de acceso telefónico y terminales locales conectados directamente ^{[ 1 ] [ 3 ] [ 4 ] [ 5 ]}
• Adaptador de pantalla y hardware de teclado incorporados directamente en la unidad del sistema, tomados en conjunto para formar una "consola" local, que puede presentarse a los usuarios y a los programas como una única terminal CRT o como múltiples terminales virtuales ^{[ 1 ].}
• emuladores de terminal de software , como xterm , Konsole , GNOME Terminal y programas Terminal , y servidores de red como el demonio rlogin y el demonio SSH , que utilizan pseudoterminales.

Los terminales proporcionan funciones de control de trabajos. De forma interactiva, el usuario del terminal puede enviar caracteres de control que suspenden el trabajo que se está ejecutando, volviendo al intérprete de comandos interactivo que inició 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 ]}

En sentido estricto, en los sistemas Unix un dispositivo terminal comprende el controlador de dispositivo tty subyacente , responsable del control físico del hardware del dispositivo mediante instrucciones de E/S y del manejo de las solicitudes de interrupción del dispositivo para la entrada y salida de caracteres, y la disciplina de línea . Una disciplina de línea es independiente del hardware real del dispositivo, y la misma disciplina de línea puede usarse tanto para un concentrador de terminales responsable del control de múltiples terminales como 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 ) es la misma en todos los dispositivos terminales. Es la disciplina de línea la responsable del eco local, la edición de línea, el procesamiento de los modos de entrada, el procesamiento de los modos de salida y la asignación de caracteres. Todas estas funciones son independientes del hardware real, ya que operan 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 la séptima edición de Unix , los sistemas BSD y sus derivados, incluyendo macOS , y Linux , cada dispositivo terminal 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 pueden insertarse y extraerse de una pila de E/S STREAMS. ^{[ 19 ]}

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 sencilla y estaba orientada principalmente a los teletipos como terminales. La entrada se introducía línea por línea, y el controlador de terminal del sistema operativo (y no los propios terminales) proporcionaba funciones básicas de edición de línea. El núcleo mantenía un búfer donde se realizaba la edición. Las aplicaciones que leían la entrada del terminal recibían el contenido del búfer solo cuando returnse pulsaba la tecla para finalizar la edición de línea. La tecla enviada desde el terminal al sistema borraba ("eliminaba") todo el contenido actual del búfer de edición y normalmente se mostraba como un símbolo " @ " seguido de una secuencia de salto de 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 búfer de edición y normalmente se mostraría como un símbolo ' # ', que los usuarios tendrían que reconocer como una indicación de "borrado" del carácter precedente (los teletipos no son físicamente capaces de borrar caracteres una vez impresos en el papel). ^{[ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 18 ]}@#

Desde el punto de vista de la programación, un dispositivo terminal tenía velocidades de transmisión y recepción en baudios , caracteres de "borrar" y "eliminar" (que realizaban la edición de línea, como se explicó), caracteres de "interrupción" y "salida" (que generaban señales a todos los procesos para los que el terminal era un terminal de control), caracteres de "inicio" y "parada" (utilizados para el control de flujo del módem ), un carácter de "fin de archivo" (que actuaba como un retorno de carro excepto que era descartado del búfer por la read()llamada al sistema y, por lo tanto, potencialmente causaba que se devolviera un resultado de longitud cero) y varias banderas de modo básicas que determinaban si el controlador de terminal del kernel emulaba el eco local , si el control de flujo del módem estaba habilitado, las longitudes de varios retardos de salida, la asignación para el carácter de retorno de carro y los tres modos de entrada. ^{[ 24 ]}

Los tres modos de entrada fueron:

modo de línea (también llamado modo "cocido")

En el modo de línea, la disciplina de línea realiza todas las funciones de edición de línea, reconoce los caracteres de control "interrupción" y "salida" y los transforma en señales que se envían a los procesos. Los programas de aplicación que leen desde la terminal reciben líneas completas una vez que el usuario ha finalizado la edición de línea pulsando Intro. ^{[ 21 ] [ 25 ]}

modo de corte

El modo cbreak es uno de los dos modos de lectura carácter por carácter. ( Stephen R. Bourne se refirió a él en tono de broma ( Bourne 1983 , p. 288) como un modo "medio cocido" y, por lo tanto, "poco hecho"). La disciplina de línea no realiza edición de línea, y las secuencias de control para las funciones de edición de línea se tratan como entrada de caracteres normal. Los programas de aplicación que leen desde la terminal reciben los caracteres inmediatamente, tan pronto como están disponibles en la cola de entrada para ser leídos. Sin embargo, los caracteres de control "interrupción" y "salida", así como los caracteres de control de flujo del módem, todavía se manejan de manera especial y se eliminan del flujo de entrada. ^{[ 26 ] [ 27 ]} 

modo sin procesar

El modo sin procesar es el otro de los dos modos de lectura carácter por carácter. La disciplina de línea no realiza edición de línea, y las secuencias de control tanto para las funciones de edición de línea como para los distintos caracteres especiales ("interrupción", "salir" y control de flujo) se tratan como entrada de caracteres normal. Los programas de aplicación que leen desde el terminal reciben los caracteres inmediatamente y reciben todo el flujo de caracteres sin alteraciones, tal como proviene del propio dispositivo terminal. ^{[ 28 ] [ 26 ] [ 27 ]}

La interfaz programática para consultar y modificar todos estos modos y caracteres de control era la ioctl()llamada al sistema . (Esto reemplazó las llamadas al sistema stty()y de la Sexta Edición de Unix). ^{[ 29 ] [ 30 ]} Aunque los caracteres "borrar" y "eliminar" 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 alteraban 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 las solicitudes de inicio de sesión y contraseña tenía que corregirse utilizando los caracteres de teclas de edición histórica heredados de los terminales de teletipo. ^{[ 23 ]}gtty()#@

Con los sistemas Unix BSD llegó 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):

• Los caracteres "suspend" y "delayed suspension" (por defecto + y + — ASCII y ) provocaron la generación de una nueva señal a los procesos en el grupo de procesos de control del terminal. ^{[ 27 ]}ControlZControlYSUBEMSIGTSTP
• Los caracteres "borrar palabra", "siguiente literal" y "reimprimir" (por defecto + , + , y + — ASCII , , y ) realizaban funciones adicionales de edición de línea. "borrar palabra" borraba la última palabra al final del búfer de edición de línea. "siguiente literal" permitía introducir cualquier carácter especial en el búfer de edición de línea (una función disponible, aunque algo inconveniente, en la Séptima Edición de Unix mediante el carácter de barra invertida). "reimprimir" hacía que la disciplina de línea reimprimiera el contenido actual del búfer de edición de línea en una nueva línea (útil cuando otro proceso en segundo plano había generado una salida que se había mezclado con la edición de línea). ^{[ 27 ]}ControlWControlVControlRETBSYNDC2

La 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 conservó toda la funcionalidad original de la Séptima Edición de Unix, y se añadió la nueva funcionalidad mediante 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 funcionalidades. ^{[ 31 ]} ioctl()

System III introdujo una nueva interfaz de programación que combinaba ioctl()las operaciones separadas de la Séptima Edición para obtener y establecer indicadores y caracteres de control en llamadas que utilizaban una termioestructura para almacenar tanto indicadores como caracteres de control, y que podían obtenerlos en una sola operación y establecerlos en otra. También dividió algunos de los indicadores de la interfaz de la Séptima Edición en varios indicadores separados y añadió algunas capacidades adicionales, aunque no admitía el control de trabajos ni las mejoras del modo "cooked" de 4BSD. ^{[ 32 ]} Por ejemplo, reemplazó los modos "cooked", "cbreak" y "raw" de la Séptima Edición con abstracciones diferentes. El reconocimiento de caracteres generadores de señales es independiente del modo de entrada, y solo existen 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 ni en BSD: modo canónico con la generación de señales deshabilitada).

Los sucesores del Sistema III, incluido el Sistema V , utilizaban 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 gran cantidad de interfaces programáticas. Si bien para la época del estándar el comportamiento de las terminales era bastante uniforme de un sistema a otro, ya que la mayoría de los sistemas Unix habían adoptado las nociones de disciplinas de línea y las capacidades de control de trabajos de BSD, la interfaz programática a las terminales mediante la ioctl()llamada al sistema era un caos. Los distintos sistemas Unix proporcionaban ioctl()operaciones diferentes, con nombres (simbólicos) distintos y diferentes indicadores. El código fuente portable debía contener una cantidad significativa de compilación condicional para adaptarse a las diferencias entre las plataformas de software, aunque todas fueran, en teoría, Unix. ^{[ 33 ]}

El estándar POSIX reemplaza ioctl()completamente el sistema con un conjunto de funciones de biblioteca (que, por supuesto, pueden implementarse internamente 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 sin cambios, salvo que ahora utilizaban tipos de datos alias para especificarlos, lo que permitía a los implementadores portarlos fácilmente a través de múltiples arquitecturas de procesador, en lugar de requerir explícitamente los tipos de unsigned shortdatos charde los lenguajes de programación C y C++ (que podrían tener tamaños inconvenientes en algunas arquitecturas de procesador). ^{[ 33 ] [ 34 ]}

POSIX también introdujo soporte para el control de trabajos, con la termiosestructura que contiene caracteres de suspensión y suspensión retardada además de los caracteres de control admitidos por System III y System V. No agregó ninguna de las extensiones de cook-mode de BSD, aunque SunOS 4.x, los sistemas System V Release 4, incluidos Solaris , HP-UX , AIX , BSD más recientes, macOS y Linux las han implementado como extensiones a termios.

Cada proceso del sistema tiene un único terminal de control o ninguno. Un proceso hereda su terminal de control de su proceso padre, y las únicas operaciones que se pueden realizar sobre un proceso son adquirir un terminal de control, por parte de un proceso que no lo tiene, y renunciar a él, por parte de un proceso que sí lo tiene. ^{[ 33 ]}

No se define ninguna forma portátil de adquirir un terminal de control, el método está definido por la implementación. El estándar define la O_NOCTTYbandera 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()sa terminal device file que no sea ya el terminal de control para algún otro proceso, sin especificar la O_NOCTTYbandera ^{[ 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. Las operaciones read()de write()E/S en un terminal por un proceso que no es miembro del grupo de procesos en primer plano del terminal harán que opcionalmente (respectivamente) se envíen señales ( SIGTTINy SIGTTOUrespectivamente) al proceso que las invoca. Varias funciones de biblioteca que alteran el modo del 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 transmisión de entrada y salida. Estos se registran en la estructura, en un formato definido por la implementación, y se accede a ellos mediante funciones de acceso, en lugar de mediante la manipulación directa de los valores de los campos, como ocurre con los campos de la estructura estandarizada. ^{[ 39 ]}

Los alias de tipo de datos tcflag_ty cc_t, así como la constante simbólica NCCSy las constantes simbólicas para los distintos indicadores de modo, nombres de caracteres de control y velocidades de transmisión, 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 de nombre similar. Esta interfaz es específica de System III y System V, y el código que la utiliza no será necesariamente portable a otros sistemas). ^{[ 40 ]}

Los campos de la estructura son (en resumen, para más detalles consulte el artículo principal ):

c_iflag

indicadores de modo de entrada para controlar la paridad de entrada, la traducción de salto de línea de entrada, el control de flujo del módem , la limpieza de 8 bits y la respuesta a una condición de "ruptura" (del puerto serie) ^{[ 34 ]}

c_oflag

indicadores de modo de salida para controlar el posprocesamiento de salida definido por la implementación, la traducción de salto de línea de salida y los retrasos de salida después de que se hayan enviado varios caracteres de control ^{[ 41 ] [ 27 ]}

c_cflag

Indicadores de control de hardware del terminal para controlar el dispositivo terminal real en lugar de la disciplina de línea: el número de bits en un carácter, tipo de paridad, control de desconexión y control de flujo de línea serie ^{[ 42 ]}

c_lflag

indicadores de control local para controlar la disciplina de línea en lugar del hardware del terminal: modo canónico, modos de eco, reconocimiento y manejo de caracteres de generación de señal y habilitación de la generación de la SIGTTOUseñal por la write()llamada al sistema ^{[ 39 ]}

Las funciones de la biblioteca son (en resumen, para más detalles consulte el artículo principal ):

tcgetattr()

consultar la configuración de atributos actual de un dispositivo terminal en una termiosestructura ^{[ 43 ]}

tcsetattr()

establecer la configuración de atributos actual de un dispositivo terminal a partir de una termiosestructura, esperando opcionalmente a que se vacíe la salida en cola y vaciando la entrada en cola ^{[ 43 ]}

cfgetispeed()

consultar la velocidad de baudios de entrada a partir de los campos definidos por la implementación en una termiosestructura ^{[ 44 ]}

cfgetospeed()

consultar la velocidad de baudios de salida de los campos definidos por la implementación en una termiosestructura ^{[ 44 ]}

cfsetispeed()

establecer la velocidad de baudios de entrada en los campos definidos por la implementación en una termiosestructura ^{[ 44 ]}

cfsetospeed()

establecer la velocidad de baudios de salida en los campos definidos por la implementación en una termiosestructura ^{[ 44 ]}

tcsendbreak()

enviar una señal de "ruptura" del módem en un terminal de dispositivo serie ^{[ 45 ]}

tcdrain()

esperar a que se vacíe la salida en cola ^{[ 45 ]}

tcflush()

descartar entrada en cola ^{[ 45 ]}

tcflow()

control de flujo de cambios ^{[ 45 ]}

tcgetpgrp()

consultar el grupo de procesos en primer plano de la terminal ^{[ 46 ]}

tcsetpgrp()

establecer el grupo de procesos en primer plano del terminal ^{[ 46 ]}

El miembro de matriz de la estructura 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 más adelante). ^{[ 43 ]}c_cc[]termios

Los caracteres especiales no modificables 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 como en el caso de System III y System V, la edición de línea opera en uno de solo dos modos: modo canónico y modo no canónico. La diferencia básica entre ellos radica en 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 a través de open()o fcntl()), los datos "están disponibles para lectura". ^{[ 48 ]}

El procesamiento de salida permanece prácticamente sin cambios con respecto a sus orígenes en los sistemas III y V. Los indicadores de control del modo de salida determinan diversas opciones:

• Se pueden insertar retornos de carro antes de cada carácter de salto de línea para traducir la semántica de salto de línea de Unix a la semántica ASCII que esperan muchos terminales. ^{[ 27 ] [ 22 ]}
• Se puede dar tiempo a los terminales para que ejecuten varios códigos de control que (en un teletipo o similar) producirían movimientos físicos del carro que podrían consumir una cantidad de tiempo significativa (desde el punto de vista del ordenador), como retrocesos, tabulaciones horizontales, retornos de carro, saltos de página y saltos de línea. ^{[ 27 ] [ 52 ]}