por que matar o trabalho de forma diferente em números de trabalho que os PIDs?

Question

Eu estava tentando demonstrar o controle do trabalho para um amigo, quando me deparei com um comportamento inesperado. Para determinados comandos, kill trabalha com o número do trabalho, mas não com o ID do processo.

Um exemplo do comportamento que eu esperava:

user@host:~$ sleep 1h &
[1] 4518
user@host:~$ sleep 2h &
[2] 4519
user@host:~$ kill %2
[2]+ Terminated   sleep 2h
user@host:~$ kill 4518
[1]+ Terminated   sleep 1h

Em ambos os casos, o sono é finalizado. Um por número de trabalho e um por PID. Agora eu tentei isso originalmente com o comando cat, e não funcionou como esperado:

user@host:~$ cat &
[1] 4521
user@host:~$ cat &
[2] 4522

[1]+ Stopped   cat
user@host:~$ kill %2
[2]+ Terminated   cat
user@host:~$ kill 4521
user@host:~$ jobs
[1]+ Stopped   cat
user@host:~$ kill 4521
user@host:~$ jobs
[1]+ Stopped   cat
user@host:~$ kill %1
[1]+ Terminated   cat

Então kill não funcionou no PID do meu processo, mas funcionou com o número do trabalho. Eu não acho que isso deveria acontecer. Por que isso acontece?

Estou usando o Debian 9 com o bash 4.4.12 (1) -release.

EDIT: No processo de tentar resolver isso, tomei conhecimento de que o estado de gato sendo "parado" pode torná-lo indiferente ao sinal padrão SIGTERM. Mas se isso for verdade, o comando kill deverá falhar com o ID do processo e o número do job. Não deveria?

    

Answer 1

O que o kill embutido realmente faz nessas circunstâncias não está documentado no manual do shell do Bourne Again, mas está documentado nos manuais de shell Z e Korn:

• Concha Korn:

  If the signal being sent is TERM (terminate) or HUP (hangup), then the job or process will be sent a CONT (continue) signal if it is stopped.

• Z shell:

  If the signal being sent is not KILL or CONT, then the job will be sent a CONT signal if it is stopped.

O manual da shell do Bourne Again deve, da mesma forma, ler algo como:

If the signal being sent is TERM or HUP and a targetted process is part of a job, then the job will be sent a CONT signal if it is stopped or job control is not available in the current terminal.

Porque é isso que realmente faz.