Como o script detecta se o emulador de terminal está sendo executado em uma sessão da área de trabalho ou não?

Tenho scripts que corro um arquivo de texto e, em seguida, abra-o em um editor. Se eu abrir uma janela do emulador de terminal na minha sessão da área de trabalho e executar o script, gostaria que o editor fosse gráfico como gedit. Mas, se eu estiver conectado através do ConnectBot no meu telefone ou similar (sem sessão na área de trabalho), gostaria que o editor fosse nano.

Atualmente, tenho que manter 2 scripts diferentes, idênticos, exceto a última etapa (ou deixar a gráfica executar, com erro desativado e, em seguida, abrir manualmente o arquivo nano). Ter dois scripts quase idênticos é ineficiente do ponto de vista de manutenção.

Um script pode detectar em qual dessas situações estou e abrir o editor correto?

(Encontrei maneiras de um script detectar se está sendo executado em uma janela do emulador de terminal ou clicando duas vezes, mas ainda não encontrei uma maneira de detectar se a janela está sendo executada em uma área de trabalho ... Acho que não conhecer a terminologia correta para o google)

Você pode usar a variável de ambiente $DISPLAYcomo acionador dentro de uma ifcondição. Normalmente, quando essa variável tem um valor, você é capaz de executar aplicativos gráficos.

Aqui está um exemplo do bash :

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

O operador -zretornará true quando o envvar $DISPLAYestiver vazio e seu script será executado nano; em todos os outros casos, ele será executado gedit.

De acordo com o comentário deste @ vurp0 :

Na maioria dos desktops modernos de Wayland (como o desktop padrão no Fedora e Ubuntu), $DISPLAYainda é definido devido à compatibilidade com versões anteriores (através do XWayland), mas para um script mais robusto seria bom testar para ambos $DISPLAYe $WAYLAND_DISPLAYter certeza.

Eu sugeriria modificar a expressão de teste da seguinte maneira:

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

Assim, os valores das duas variáveis ​​serão concatenados em uma sequência comum, que será processada pelo operador -z.

Referências:

• Guia Avançado de Bash-Scripting: 7. Testes
• Guia Avançado de Bash-Scripting: 7.1. Construções de teste
• Guia Avançado de Script Bash: 7.3. Outros operadores de comparação

Normalmente, os terminais virtuais usam /dev/ptspseudo-terminais . Portanto, com base na saída do ttycomando, podemos criar uma casedeclaração simples para lidar com a abertura de um editor específico:

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

Ou formatado mais bem:

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

Comparado ao uso de variáveis ​​de ambiente, isso é um pouco mais confiável e, considerando que usa a caseinstrução com ttycomando um pouco mais portátil. O que provavelmente seria melhor é combinar os dois, com testes extras, como"/dev/tty"*) [ -n "$DISPLAY" ] && gedit ;;

Isto é o que eu tenho usado:

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

O motivo desse código foi esta pergunta: O atalho da área de trabalho para o script Bash trava e queima

Você pode modificá-lo para ficar assim:

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