Come fare in modo che lo script rilevi se l'emulatore di terminale è in esecuzione in una sessione desktop o no?

Ho degli script che eseguo per scrivere un file di testo, quindi aprirlo in un editor. Se apro una finestra dell'emulatore di terminale nella mia sessione desktop ed eseguo lo script, vorrei che l'editor fosse grafico come gedit. Ma, se ho effettuato l'accesso tramite ConnectBot sul mio telefono o simili (nessuna sessione desktop), mi piacerebbe l'editor nano.

Attualmente devo mantenere 2 diversi script, identici ad eccezione dell'ultimo passaggio (o lasciare che quello grafico venga eseguito, errore spento, quindi aprire manualmente il file nano). Avere due script per lo più identici è inefficiente dal punto di vista della manutenzione.

Uno script può rilevare in quale di queste situazioni mi trovo e aprire l'editor corretto?

(Ho trovato il modo per uno script di rilevare se è in esecuzione in una finestra dell'emulatore di terminale o facendo doppio clic, ma non ho ancora trovato un modo per rilevare se la finestra è in esecuzione su un desktop ... Non penso di conoscere la terminologia corretta per google per)

È possibile utilizzare la variabile di ambiente $DISPLAYcome trigger all'interno di una ifcondizione. Di solito, quando questa variabile ha un valore, è possibile eseguire applicazioni grafiche.

Ecco un esempio bash :

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

L'operatore -zrestituirà true quando envvar $DISPLAYè vuoto e lo script verrà eseguito nano, in tutti gli altri casi verrà eseguito gedit.

Secondo questo commento di @ vurp0 :

Sulla maggior parte dei desktop Wayland moderni (come il desktop predefinito in Fedora e Ubuntu), $DISPLAYè ancora impostato a causa della compatibilità con le versioni precedenti (tramite XWayland), ma per uno script più robusto sarebbe bene testare entrambi $DISPLAYe $WAYLAND_DISPLAYessere sicuri.

Suggerirei di modificare l'espressione del test nel modo seguente:

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

Pertanto, i valori delle due variabili verranno concatenati in una stringa comune, che verrà elaborata dall'operatore -z.

Riferimenti:

• Guida avanzata agli script di Bash: 7. Test
• Guida avanzata agli script di Bash: 7.1. Costrutti di prova
• Guida avanzata agli script di Bash: 7.3. Altri operatori di confronto

I terminali tipicamente virtuali usano /dev/ptspseudo-terminali . Quindi, in base all'output del ttycomando, possiamo creare una semplice caseistruzione per gestire l'apertura di un particolare editor:

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

O formattato più bene:

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

Rispetto all'utilizzo delle variabili d'ambiente, questo è leggermente più affidabile e considerando che usa caseun'istruzione con ttycomando leggermente più portatile. Ciò che probabilmente sarebbe meglio è combinare entrambi, con test extra, come ad esempio"/dev/tty"*) [ -n "$DISPLAY" ] && gedit ;;

Questo è quello che ho usato:

# $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

Il motivo di questo codice era questa domanda: il collegamento sul desktop allo script Bash si arresta in modo anomalo e si brucia

Puoi modificarlo in questo modo:

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