¿Es posible ejecutar un script de diálogo / whiptail en un TTY desde otro?

El origen de esta pregunta, para mí, es poder ejecutar un comando whiptail en un %pre script desde un archivo kickstart al instalar una distribución personalizada basada en Centos. Sin embargo, el comportamiento observado en Anaconda se puede reproducir fácilmente a través de los terminales virtuales de cualquier sistema Linux.

Para ejecutar el comando whiptail en Anaconda como kickstart %pre script es necesario cambiar TTY y ejecutar el comando en este nuevo TTY. La sugerencia predominante sobre cómo hacer esto es:

%pre
exec </dev/tty6 >/dev/tty6 2>/dev/tty6
chvt 6

# then execute your command, for example:
whiptail --inputbox "Enter some text..." 10 30

# switch back to the original TTY
chvt1
exec </dev/tty1 >/dev/tty1 2>/dev/tty1
%end

Al usar este método, el cuadro de diálogo de whiptail se representa correctamente en el nuevo TTY, sin embargo, no puede haber interacción con el cuadro de diálogo, por ejemplo, presionando tab, en lugar de cambiar entre los elementos de entrada de texto, "Aceptar" y "Cancelar", en realidad inserta una pestaña en el cuadro de entrada de texto. Del mismo modo, el uso de las teclas de flecha hace que se escriban secuencias de escape en el cuadro de diálogo:

Este comportamiento también se observa cuando se usa python snack (usa la misma biblioteca que whiptail - libnewt) y el diálogo.

Por supuesto, solo podría usar un script de shell interactivo, en lugar de usar el látigo, pero me preguntaba si alguien tenía alguna sugerencia sobre por qué se ve este comportamiento, ya que habría pensado que los únicos requisitos para que esto funcione serían para redireccionar correctamente los flujos de entrada y salida.

TL; DR

Estoy interesado en crear un script que contenga comandos whiptail / dialog que puedan ejecutarse en un TTY y que la salida / entrada del script vaya a / provenga de un TTY diferente.

Esto me funcionó (Anaconda, Fedora 20):

%pre --log=/tmp/ks_pre.log
#!/bin/bash

# Backup fds in temporal ones
exec {STDOUTBACK}>&1
exec {STDERRBACK}>&2

# Go to current terminal for pre% section
exec 1>>/dev/pts/0
exec 2>>/dev/pts/0

# Show message
whiptail --yesno 'Do you like StackOverflow?' --yes-button 'Yes' --no-button 'No' 10 70
if [ $? = 1 ]
then
    echo 'User sucks' >> /tmp/ks_pre.log
else
    echo 'User rocks' >> /tmp/ks_pre.log
fi

# Restore fds
exec 1>&$STDOUTBACK
exec 2>&$STDERRBACK

# Close temporal fds
exec {STDOUTBACK}>&-
exec {STDERRBACK}>&-

%end

Posibles preguntas:

1. Por que usaste /dev/pts/0?

   Porque desde la consola Anaconda descubrí qué dispositivo estaba siendo utilizado como stdin para los scripts que se ejecutan en pre% section. Supongo que podría ser otro dependiendo de las versiones de RedHat y Fedora. Pero es realmente fácil averiguar cuál es el correcto para su caso.

2. Que son los exec {STDOUTBACK}>&1 y exec {STDOUTBACK}>&- ¿cosas?

   Ve a leer tu man bash y busca el REDIRECTION Sección, donde puedes encontrar lo siguiente:

Cada redirección que puede estar precedida por un número de descriptor de archivo puede ir precedida por una palabra del formulario          {varname}. En este caso, para cada operador de redireccionamiento excepto & gt; & amp; - y & lt; & amp; -, el shell asignará un archivo          Descriptor mayor a 10 y asignarlo a varname. Si & gt; & amp; - o & lt; & amp; - está precedido por {varname}, el valor de var-          nombre define el descriptor de archivo para cerrar.

Esto debería ser un comentario, pero ...

Tienes que manipular stdin, stderr y stdout para que whiptail produzca una variable.

x=`whiptail  --inputbox "hello" 10 40  3>&1 1>&2 2>&3`

Esto pone la salida en / tmp / x:

whiptail  --inputbox "hello" 10 40  3>/tmp/x 1>&2 2>&3