Por que a execução de um processo inválido com '&' fecha o terminal?

Question

Ao executar, por exemplo, a& no bash, a janela do terminal é fechada, onde eu esperaria que um novo processo fosse iniciado seguido por uma mensagem de erro (semelhante a, por exemplo, grep & ).

O que está causando esse comportamento? É intencional?

edit: conforme solicitado,

yuvalw@UX410UQK:~$ echo $-
himBH

Eu também tentei abrir outro bash no bash para obter saída adicional. Minha entrada é bash seguida por a& e algumas novas linhas:

yuvalw@UX410UQK:~$ bash
yuvalw@UX410UQK:~$ a&
[1] 15323
yuvalw@UX410UQK:~$ exit
yuvalw@UX410UQK:~$ a: command not found

yuvalw@UX410UQK:~$

aqui chamando a& novamente fechará a janela do terminal.

edit2: mais ecos

yuvalw@UX410UQK:~$ echo "$BASH_VERSION $SHELLOPTS $BASHOPTS"
4.3.48(1)-release braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor checkwinsize:cmdhist:complete_fullquote:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:progcomp:promptvars:sourcepath

armadilha:

yuvalw@UX410UQK:~$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU

digite exit:

yuvalw@UX410UQK:~$ type exit
exit is a shell builtin

PROMPT_COMMAND (vazio):

yuvalw@UX410UQK:~$ echo $PROMPT_COMMAND

PS1:

yuvalw@\UX410UQK:~$ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[3[01;32m\]\u@\h\[3[00m\]:\[3[01;34m\]\w\[3[00m\]\$

edite 3: Abrindo um novo terminal, não parece que isso aconteça, e eu posso executar a& muito bem, mas depois de cd ing por um tempo, o problema retorna. Em ambos os casos, o comando_not_found_handle parece o mesmo.

yuvalw@yuvalw-UX410UQK:~$ type command_not_found_handle

command_not_found_handle is a function
command_not_found_handle () 
{ 
    if [ -x /usr/lib/command-not-found ]; then
        /usr/lib/command-not-found -- "$1";
        return $?;
    else
        if [ -x /usr/share/command-not-found/command-not-found ]; then
            /usr/share/command-not-found/command-not-found -- "$1";
            return $?;
        else
            printf "%s: command not found\n" "$1" 1>&2;
            return 127;
        fi;
    fi
}

    

Answer 1

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.

No caso geral, no entanto, é improvável que o bug acione como o shell também se coloca em primeiro plano antes de gravar seu prompt, portanto, o 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 .