Esse foi um bug em bash
, corrigido em 4.4.
Se você tem o command_not_found_handle()
hook definido (que é invocado quando um comando não é encontrado), bash
o coloca em primeiro plano mesmo se o comando não encontrado foi iniciado em background. / p>
Em seguida, dependendo do momento, se o shell ler a linha de comando do dispositivo tty após colocar command_not_found_handle
em primeiro plano, esse read()
retornará com um erro EIO
, como acontece quando um processo em segundo plano é lido um dispositivo terminal e ignora o sinal SIGTTIN.
bash
trataria isso como fim do arquivo na entrada do usuário como se você tivesse pressionado Ctrl + D
Pode-se reproduzir o problema fazendo:
$ command_not_found_handle() { sleep 20; }
$ a &
$ x
Mesmo se o primeiro read()
for bem-sucedido porque foi iniciado antes , o command_not_found_handle
será colocado em primeiro plano, a segunda e as subsequentes leituras depois que você pressionar x
falhará e fará com que o shell saia .
Com o command_not_found_handle
padrão enviado no Ubuntu,
$ a & true &
Também faz com que o shell saia como o SIGCHLD quando true
retornar interrompe o primeiro read()
e faz com que um segundo seja iniciado com o manipulador ainda em execução em primeiro plano.
command_not_found_handle
tem que se colocar em primeiro plano (fazer o tcsetpgrp()
) no momento certo (depois que o processo principal do shell se coloca em primeiro plano e antes de começar a ler o dispositivo tty).
Foi corrigido em abril de 2015, com este commit (4 / 23 em CWRU.log) seguindo um relatório para um problema relacionado por Valentin Bajrami .