Fazendo zsh jobs -p se comportar como no bash

jobsrelatórios sobre jobs, que podem ter mais de um processo.

Quando interativas, as tarefas são colocadas em grupos de processos, para que possam ser suspensas/reiniciadas/interrompidas como um todo.

jobs -p(em ambos zshe bash) retorna o ID do grupo de processos de cada trabalho, não os IDs de processo de todos os processos no trabalho.

Quando o shell não é executado interativamente (onde não há controle de tarefas), o shell informa o pid do processo que seria o líder do grupo de processos se houvesse controle de tarefas (que pode não ser o mesmo retornado em $!a propósito).

$ sleep 1 | sleep 20 &
[1] 29643 29644
$ jobs -p
[1]  + 29643 done       sleep 1 |
             running    sleep 20

O zsh relata que para o job 2 do pgid 29643, o zsh iniciou 2 processos, um dos quais já está concluído e o outro ainda em execução.

Se você deseja obter os pgids apenas como em bash, você pode canalizar isso:

awk '/^\[/{print $3}'

Se você deseja obter os pids no trabalho (somente aqueles iniciados pelo shell), você pode olhar para o $jobstatesarray associativo especial:

$ typeset jobstates
jobstates=( 1 'running:+:29643=done:29644=running' )

Para extrair os pids dos processos ainda em execução no job 1:

$ echo ${${(M)${(s/:/)jobstates[1]}:#*=running}%=*}
29644

Agora, se você deseja matar esses trabalhos, você deseja matar os grupos de processos (em shells interativos), ou seja, todos os trabalhos, não um processo aleatório no trabalho.

Você pode matar o grupo de processos de id 29643 com kill -- -29643, kill 29643apenas mataria o processo de id 29643 (que já está morto em nosso exemplo acima).

Aqui, faria mais sentido passar números de tarefas em vez de pid ou pgid (que não funcionaria em shells não interativos) para matar. É para isso que servem os números de trabalho:

kill %${(k)^jobstates}

Infelizmente, não acho que bashtenha um equivalente confiável.

bash-4.4$ sleep $(: '
> [213] ...') 2134 &
[1] 29856
bash-4.4$ jobs
[1]+  Running                 sleep $(: '
[213] ...') 2134 &

É difícil extrair os números de trabalho de forma confiável a partir disso. (Também acho que nem while kill %; do continue; donefunciona por causa do que parece ser algum bug de condição de corrida).

Observe que, quando não estiver sendo executado interativamente, não há controle de trabalho, portanto, quando você faz kill %1para matar o trabalho número 1, esse trabalho não possui um grupo de processos. Então, como uma aproximação de um homem pobre, o shell (ambos bashe zsh) matará cada processo que conhece individualmente. Em nosso exemplo acima, em vez de:

kill(-29643, SIGTERM);

vai fazer:

kill(29643, SIGTERM);
kill(29644, SIGTERM);

Ele não matará os outros processos (se houver) que esses 2 processos geraram, embora ainda seja melhor do que matar apenas 29643 como em sua kill $(jobs -p)abordagem.