não pode matar o processo de gedit do seu PID

1

Esta é a sequência de comandos, gedit começa, mas não pode ser eliminada de seu ID de processo

$ gedit&
$ t=$!
$ echo $t
4824
$ kill $t
bash: kill: (4824) - No such process

Funcionaria muito bem para um processo de sleep , como

sleep 999&
[1] 4881
$ t=$!
$ echo $t
4881
$ kill $t
$ ps -p $t
[1]   Terminated              sleep 999

Qual é a diferença? Como o processo gedit pode ser encerrado?

    
por nightcod3r 16.11.2016 / 11:18

3 respostas

5

O gedit process já terminou .

Lembre-se de como os aplicativos do Windows funcionavam principalmente no Win16 dias antes do Win32 aparecer e acabar com isso: onde havia hInstance e hPrevInstance , tentar executar uma segunda instância de muitos aplicativos simplesmente passava as coisas para o primeira instância, e isso dificultou as coisas para as ferramentas de script de comando (como Take Command) porque uma pessoa invocaria uma aplicação uma segunda vez, ela estaria visível na tela como uma janela adicionada, mas, no que diz respeito ao interpretador de comandos, processo de criança que acabou de executar imediatamente saiu?

Bem, o GNOME trouxe o comportamento do Win16 de volta para o Linux.

Com aplicativos GIO como gedit , o aplicativo se comporta da seguinte maneira:

  • Se não houver um "servidor" registrado chamado org.gnome.gedit no Desktop Bus por usuário / por login, gedit decidirá que é a primeira instância. torna-se o servidor org.gnome.gedit e continua a ser executado.
  • Se houver um "servidor" registrado chamado org.gnome.gedit no Desktop Bus por usuário / por login, gedit decidirá que é uma segunda instância ou uma instância subsequente. Ele constrói mensagens do Desktop Bus para a primeira instância, passando adiante suas opções e argumentos da linha de comandos, e simplesmente sai .

Então, o que você vê depende se você já tem o servidor gedit em execução. Se você não tiver, você estará no lugar de sebvieira e se perguntando por que você não está vendo o comportamento descrito. Se tiver, você estará no seu lugar e vendo o processo gedit terminar quase imediatamente, especialmente porque você não deu nenhuma opção ou argumento de linha de comando para enviar para a "primeira instância". Daí a razão pela qual não há mais um processo com esse ID.

Muita diversão ocorre quando, conforme mencionado acima, o Desktop Bus por login é alterado para o "novo" estilo de um Desktop Bus por usuário e, de repente, não há uma relação de 1: 1 entre um Desktop Bus e um X exibir mais. Aplicativos de instâncias de bus de usuário único de repente precisam ser capazes de falar simultaneamente com múltiplos monitores X.

Existe mais hilaridade quando as pessoas tentam executar gedit como superusuário via sudo , já que ele não pode se conectar a um Desktop Bus por usuário ou se conectar ao Desktop Bus errado (do superusuário).

Existe uma proposta para dar ao gedit uma opção de linha de comando que faz com que o processo que é invocado seja apenas o aplicativo de edição real , para que gedit seja útil como o editor apontou. pela variável de ambiente EDITOR (o que não é para muitos usos comuns de EDITOR , de crontab para git , quando apenas sai imediatamente). Esta proposta ainda não se tornou realidade.

Nesse meio tempo, as pessoas têm várias maneiras de ter uma segunda instância simples de um "editor de texto simples", como invocar uma nova instância do Desktop Bus, privada para a invocação de gedit , com dbus-run-session . É claro que isso tende a acelerar outros servidores do GNOME Desktop Bus nesse barramento privado, já que eles são invocados por gedit , tornando-o "leve".

A cereja no topo do bolo é quando você segue esta recomendação ou uma como esta e interpõe uma concha função chamada gedit que remove imediatamente o processo gedit da lista de tarefas do shell. O processo não apenas termina rapidamente, mas você não o vê mais tarde com kill ou ps , mas o shell nem mesmo o monitora como um trabalho controlado por shell.

Leitura adicional

por 16.11.2016 / 13:05
0

Desculpe, mas funciona para mim:

$ gedit&
[1] 9391
$ t=$! 
$ echo $t
9391
$ kill $t
[1]+  Terminated         gedit

Verifique se o processo ainda existe executando ps -ef ou pidof gedit . Em caso afirmativo, você também pode fazer apenas kill $(pidof gedit)

    
por 16.11.2016 / 11:59
0

Eu tentei o seguinte código e ele funcionou dentro do script, experimente

     gedit&
     t=$! 
     echo $t
    #sleep 2
     kill -9 $t
    
por 16.11.2016 / 12:50