¿Qué significa "el dispositivo de entrada no es un TTY" exactamente en la salida "docker run"?

Este es un comando que funciona:

$ echo 'hi there' | docker run -i ubuntu cat
hi there

Este es un comando que responde con un mensaje de error:

$ echo 'hi there' | docker run -it ubuntu cat
the input device is not a TTY

Me gustaría averiguar exactamente qué sucede aquí. No solo "eliminar -t y se solucionará".

Sé que docker run's -topción significa 'Asignar un pseudo-TTY', y he leído descripciones históricas de lo que significa TTY , pero no me ayude a entender qué tipo de contrato se viola aquí.

Esta respuesta me ayudó a comprender:

• de forma predeterminada (sin opciones -ini -topciones) un contenedor Docker solo envía su salida a STDOUT,
• con -iopción viene la conexión a STDIN,
• -tla opción extrae un controlador de interfaz de terminal , que funciona sobre STDIN / STDOUT. Y cuando se conecta un controlador de terminal, la comunicación con un contenedor debe cumplir con el protocolo de interfaz de terminal . Tubería de una cadena no.

Respuesta tardía, pero podría ayudar a alguien

docker run/exec -iconectará el STDIN del comando dentro del contenedor al STDIN del docker run/execmismo.

Entonces

• docker run -i alpine catle da una línea vacía en espera de entrada. Escriba "hola" obtendrá un eco "hola". El contenedor no saldrá hasta que envíe CTRL + D porque el proceso principal catestá esperando la entrada del flujo infinito que es la entrada terminal del docker run.
• Por otro lado echo "hello" | docker -i run alpine cat, imprimirá "hola" y saldrá inmediatamente porque se catda cuenta de que la secuencia de entrada ha finalizado y termina por sí misma.

Si intenta docker psdespués de salir de cualquiera de los anteriores, no encontrará ningún contenedor en ejecución. En ambos casos, el catmismo ha terminado, por lo tanto, la ventana acoplable ha terminado el contenedor.

Ahora para "-t", esto le dice al proceso principal dentro de Docker que su entrada es un dispositivo terminal.

Entonces

• docker run -t alpine catle dará una línea vacía, pero si intenta escribir "hola", no obtendrá ningún eco. Esto se debe a que mientras catestá conectado a una entrada de terminal, esta entrada no está conectada a su entrada. El "hola" que escribió no alcanzó la entrada de cat. catestá esperando una entrada que nunca llega.
• echo "hello" | docker run -t alpine cat también le dará una línea vacía y no saldrá del contenedor en CTRL-D pero no obtendrá un eco "hola" porque no pasó -i

Si envía CTRL + C, recupera su shell, pero si lo intenta docker psahora, verá que el catcontenedor sigue ejecutándose. Esto se debe a catque todavía está esperando una secuencia de entrada que nunca se cerró. No he encontrado ningún uso útil para el -tsolo sin ser combinado con -i.

Ahora, para -itjuntos. Esto le dice a cat que su entrada es una terminal y al mismo tiempo conecte esta terminal a la entrada de la docker runcual es una terminal. docker run/execse asegurará de que su propia entrada sea de hecho un tty antes de pasarla cat. Es por eso que obtendrá un input device is not a TTYsi lo intenta echo "hello" | docker run -it alpine catporque en este caso, la entrada de docker runsí mismo es la tubería del eco anterior y no el terminal donde docker runse ejecuta

Finalmente, ¿por qué necesitaría pasar -tsi -ihará el truco de conectar su entrada a catla entrada de? Esto se debe a que los comandos tratan la entrada de manera diferente si es un terminal. Esto también se ilustra mejor con un ejemplo.

• docker run -e MYSQL_ROOT_PASSWORD=123 -i mariadb mysql -uroot -ple dará un mensaje de contraseña. Si escribe la contraseña, los caracteres se imprimen visiblemente.
• docker run -i alpine shte dará una línea vacía. Si escribe un comando como lsse obtiene una salida, pero no obtendrá un mensaje o una salida de color.

En los últimos dos casos, obtiene este comportamiento porque mysql, además de shellno tratar la entrada como un tty, no utilizó el comportamiento específico de tty como enmascarar la entrada o colorear la salida.

Un tty indica que tiene un terminal, algo que proporcionaría xterm o una de las muchas interfaces de línea de comandos de Linux. Necesita un teclado y una interfaz de salida de texto asociada. Las razones típicas para querer esto son la compatibilidad con la salida de texto en color, el manejo de varias combinaciones de teclas (como las teclas de flecha) y la capacidad de mover el cursor por la pantalla.

Cuando canaliza un comando en la ventana acoplable como lo echomuestra su ejemplo, esa canalización es la entrada y esa canalización no tiene una interfaz tty, es solo una secuencia de texto. Intentar crear un tty con eso fallará como indica el mensaje de error.