¿Cómo hacer que el script detecte si el emulador de terminal se ejecuta en una sesión de escritorio o no?

Tengo scripts que ejecuto que escriben un archivo de texto, luego lo abro en un editor. Si abro una ventana de emulador de terminal en mi sesión de escritorio y ejecuto el script, me gustaría que el editor sea gráfico como gedit. Pero, si estoy conectado a través de ConnectBot en mi teléfono o similar (sin sesión de escritorio), me gustaría que fuera el editor nano.

Actualmente tengo que mantener 2 scripts diferentes, idénticos excepto por el último paso (o dejar que se ejecute el gráfico, error apagado, luego abrir manualmente el archivo nano). Tener dos scripts en su mayoría idénticos es ineficiente desde el punto de vista del mantenimiento.

¿Puede un script detectar en cuál de estas situaciones estoy y abrir el editor correcto?

(He encontrado formas para que un script detecte si se está ejecutando en una ventana del emulador de terminal o haciendo doble clic, pero aún no he encontrado una manera de detectar si la ventana se está ejecutando en un escritorio ... No creo que conoce la terminología correcta para google)

Puede usar la variable de entorno $DISPLAYcomo desencadenante dentro de una ifcondición. Por lo general, cuando esta variable tiene un valor, puede ejecutar aplicaciones gráficas.

Aquí hay un ejemplo de bash :

if [[ -z $DISPLAY ]]
then
    nano
else
    gedit
fi

El operador -zdevolverá true cuando envvar $DISPLAYesté vacío y su script se ejecutará nano, en todos los demás casos se ejecutará gedit.

De acuerdo con este comentario de @ vurp0 :

En la mayoría de los escritorios modernos de Wayland (como el escritorio predeterminado en Fedora y Ubuntu), $DISPLAYtodavía está configurado debido a la compatibilidad con versiones anteriores (a través de XWayland), pero para un script más robusto sería bueno probar ambos $DISPLAYy $WAYLAND_DISPLAYestar seguro.

Sugeriría modificar la expresión de prueba de la siguiente manera:

[[ -z ${DISPLAY}${WAYLAND_DISPLAY} ]]

Por lo tanto, los valores de las dos variables se concatenarán en una cadena común, que será procesada por el operador -z.

Referencias

• Guía avanzada de secuencias de comandos Bash: 7. Pruebas
• Guía avanzada de secuencias de comandos Bash: 7.1. Construcciones de prueba
• Guía avanzada de secuencias de comandos Bash: 7.3. Otros operadores de comparación

Por lo general, los terminales virtuales usan /dev/ptspseudo terminales . Entonces, en base a la salida del ttycomando, podemos construir una casedeclaración simple para manejar la apertura de un editor particular:

case "$(tty)" in ; "/dev/pts"*) nano ;; "/dev/tty"*) gedit ;; ;esac

O formateado más bien:

case "$(tty)" in
    "/dev/pts"*) gedit ;; 
    "/dev/tty"*) nano ;;
    *) echo "Not suitable tty" > /dev/stderr ;;
esac

En comparación con el uso de variables de entorno, esto es un poco más confiable y teniendo en cuenta que usa una caseinstrucción con un ttycomando un poco más portátil. Lo que probablemente sería mejor es combinar ambos, con pruebas adicionales, como"/dev/tty"*) [ -n "$DISPLAY" ] && gedit ;;

Esto es lo que he estado usando:

# $TERM variable may be missing when called via desktop shortcut
CurrentTERM=$(env | grep TERM)
if [[ $CurrentTERM == "" ]] ; then
    notify-send --urgency=critical "$0 cannot be run from GUI without TERM environment variable."
    exit 1
fi

La razón de este código fue esta pregunta: el acceso directo del escritorio a la secuencia de comandos Bash se bloquea y se quema

Puede modificarlo para que se vea así:

# $TERM variable may be missing when called via desktop shortcut
CurrentTERM=$(env | grep TERM)
if [[ $CurrentTERM == "" ]] ; then
    nano ...
else
    gedit ...
fi