Em geral, não é possível que um shell “adote” um trabalho. Para um shell, um trabalho significa algumas coisas:
- Associe um identificador de trabalho a um ID de processo.
- Exibe seu status (em execução, suspenso, morto).
- Notifique o usuário quando o status mudar.
- Envie um sinal SIGHUP quando o terminal desaparecer.
- Controle se o trabalho “possui” o terminal (seja o grupo de processos de primeiro plano).
A maioria deles não requer nenhuma associação especial entre o shell e o trabalho, mas há alguns que fazem isso:
- Para notificar o usuário quando o status é alterado, o shell se baseia no recebimento de um sinal SIGCLD . Este sinal é enviado pelo kernel para o processo pai do processo inicial da tarefa.
- Para controlar o acesso ao terminal, o shell precisa estar na mesma sessão que o trabalho.
Não é possível que um processo adote outro processo nem associe um processo a uma sessão existente. Então, para suportar a adoção, o shell teria que gerenciar um status parcial. Os shells usuais não implementaram isso.
No caso especial em que o job é inicialmente iniciado por esse shell e depois desfeito, esses problemas não surgem. Mas nenhum dos shells usuais implementou uma exceção à exceção que permite que eles adicionem um job se inicialmente o tivessem iniciado.
Em seu cenário, normalmente seria mais conveniente iniciar o trabalho em uma sessão de tela ou tmux e usar o PID se você quiser suspendê-lo ou reiniciá-lo.