O atalho do Desktop para o script Bash trava e queima

Question

Eu criei um link no Nautilus no diretório ~/bin para um script bash localizado lá. Então eu cortei e colei o link no diretório ~/Desktop .

Quando clico nele, nada aparece na tela. Se eu clicar com o botão direito no link e selecionar Run nada aparece. Mas eu sei que está em execução porque conky mostra várias CPUs com alta carga. O% normal da CPU deve ser de 5% a 8%, mas está em torno de 79%. Cada instância do link está levando cerca de 5% da CPU, mais systemd está recebendo 5% da CPU para o registro no diário. A temperatura é normalmente < 50C, mas neste caso, gira em torno de 75C.

Eu vasculhei journalctl e encontrei o problema de ofender / loop:

$ journalctl -b-1 | grep 'TERM environment variable not set.' | wc
  35763  357630 3325959

Eu verifiquei o link e ele parece ok:

lrwxrwxrwx  1 rick rick     30 Mar 26 10:14 Link to grub-display.sh -> /home/rick/bin/grub-display.sh*

Nota este é um novo script que acabei de postar hoje: Como exibir o menu e as opções do grub sem inicializar? . No script, é usado o comando clear , que está vinculado a TERM mensagens de erro em outro thread aqui e aqui:

Algumas das soluções para a mensagem de erro journalctl acima exigem que você analise:

$ env | grep TERM
TERM=xterm-256color

Eu estou querendo saber se isso é algo que ~/.bashrc faz quando você abre um terminal, mas falta quando um atalho de desktop (link) executa um comando de terminal diretamente?

O script grub-display.sh bash é executado perfeitamente em uma janela de terminal.

Como posso consertar esse link mal-intencionado do Nautilus criado para mim?

    

Answer 1

O problema é que o script depende da variável ambiental TERM que está sendo configurada. O Ubuntu Unity Desktop não tem isso inicializado quando os scripts são chamados. Se você abrir um terminal com Ctrl + Alt + T , a variável será configurada.

Para testar seu sistema, crie um pequeno script chamado test-term.sh e faça com que pareça:

#!/bin/bash

#See if $TERM has been set when called from Desktop shortcut

echo TERM environment variable: $TERM > ~/Downloads/test-term.txt
echo "Using env | grep TERM output below:" >> ~/Downloads/test-term.txt
env | grep TERM >> ~/Downloads/test-term.txt

exit 0

Crie um link no Nautilus para test-term.sh e execute o link. Em seguida, verifique o arquivo de saída:

$ cat ~/Downloads/test-term.txt

TERM environment variable: dumb
Using env | grep TERM output below:
(... blank line appears here ...)

Como você pode ver, a variável de ambiente TERM está em branco quando o comando env | grep TERM é usado. Além disso, a variável $TERM está configurada para dumb , o que não combina muito bem com o comando dialog baseado em cores, suportado pelo mouse.

Solução clichê

A solução de curto prazo foi incluir código clichê no topo dos dois scripts em questão:

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

    

Answer 2

A "solução" é não executar programas fora do ambiente requerido repetidamente sem verificar seu status de saída . dialog , whiptail , etc. são destinados a terminais, então, é claro, exigem que o TERM seja definido. Então você deve executar esses scripts em um terminal. A mesma coisa teria acontecido com o seu zenity "avançado", yad, etc. se for executado sem um display X11 / Wayland.

Em seu script, você verifica a saída de dialog ao redirecionar a saída de erro com a saída normal. Portanto, quando a caixa de diálogo "trava e queima" e imprime uma mensagem de erro, você compara a saída de erro em suas condições if! Por que você faria isso?