Comment faire pour que le script détecte si l'émulateur de terminal s'exécute dans une session de bureau ou non?

J'ai des scripts que j'exécute qui écrivent un fichier texte, puis l'ouvrent dans un éditeur. Si j'ouvre une fenêtre d'émulateur de terminal dans ma session de bureau et que j'exécute le script, j'aimerais que l'éditeur soit graphique tel que gedit. Mais, si je suis connecté via ConnectBot sur mon téléphone ou similaire (pas de session de bureau), j'aimerais que l'éditeur soit nano.

Actuellement, je dois conserver 2 scripts différents, identiques à l'exception de la dernière étape (ou laisser le graphique s'exécuter, erreur désactivée, puis ouvrir manuellement le fichier nano). Avoir deux scripts pour la plupart identiques est inefficace du point de vue de la maintenance.

Un script peut-il détecter dans laquelle de ces situations je me trouve et ouvrir l'éditeur approprié?

(J'ai trouvé un moyen pour un script de détecter s'il s'exécute dans une fenêtre d'émulateur de terminal ou en double-cliquant dessus, mais je n'ai pas encore trouvé de moyen de détecter si la fenêtre s'exécute sur un bureau ... Je ne pense pas que je connaître la bonne terminologie pour google)

Vous pouvez utiliser la variable d'environnement $DISPLAYcomme déclencheur dans une ifcondition. Habituellement, lorsque cette variable a une valeur, vous pouvez exécuter des applications graphiques.

Voici un exemple bash :

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

L'opérateur -zrenverra true lorsque l'envvar $DISPLAYest vide et votre script s'exécutera nano, dans tous les autres cas, il s'exécutera gedit.

Selon le commentaire de @ vurp0 :

Sur la plupart des bureaux Wayland modernes (comme le bureau par défaut dans Fedora et Ubuntu), il $DISPLAYest toujours défini en raison de la compatibilité descendante (via XWayland), mais pour un script plus robuste, il serait bon de tester les deux $DISPLAYet $WAYLAND_DISPLAYd'être sûr.

Je suggère de modifier l'expression de test de la manière suivante:

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

Ainsi, les valeurs des deux variables seront concaténées dans une chaîne commune, qui sera traitée par l'opérateur -z.

Références:

• Guide avancé de Bash-Scripting: 7. Tests
• Guide avancé de Bash-Scripting: 7.1. Constructions de test
• Guide avancé de Bash-Scripting: 7.3. Autres opérateurs de comparaison

Les terminaux virtuels utilisent généralement des /dev/ptspseudo-terminaux . Ainsi, sur la base de la sortie de la ttycommande, nous pouvons créer une caseinstruction simple pour gérer l'ouverture d'un éditeur particulier:

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

Ou mieux formaté:

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

Comparé à l'utilisation de variables d'environnement, c'est un peu plus fiable et considérant qu'il utilise une caseinstruction avec une ttycommande légèrement plus portable. Ce qui serait probablement le mieux est de combiner les deux, avec des tests supplémentaires, tels que"/dev/tty"*) [ -n "$DISPLAY" ] && gedit ;;

Voici ce que j'utilise:

# $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 raison de ce code était cette question: le raccourci du bureau vers le script Bash plante et brûle

Vous pouvez le modifier pour ressembler à ceci:

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