unix bash – ¿Por qué ejecutar un proceso no válido con '&' cierra la terminal?

Pregunta:

Cuando se ejecuta, por ejemplo, a& en bash, la ventana de la terminal se cierra, donde esperaría que se inicie un nuevo proceso seguido de un mensaje de error (similar a, por ejemplo, grep & ).

¿Qué está causando este comportamiento? ¿Es intencional?

editar: según lo solicitado,

yuvalw@UX410UQK:~$ echo $-
himBH

También intenté abrir otro bash en bash para obtener resultados adicionales. Mi entrada es bash seguido de a& y algunas líneas nuevas:

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

yuvalw@UX410UQK:~$

aquí, llamar a& nuevo cerrará la ventana de la terminal.

edit2: más 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

trampa:

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

tipo salida:

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

PROMPT_COMMAND (vacío):

yuvalw@UX410UQK:~$ echo $PROMPT_COMMAND

PS1:

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

edición 3: Al abrir una nueva terminal, no parece que esto suceda, y puedo ejecutar a& muy bien, pero después de hacer cd durante un rato, el problema vuelve. En ambos casos, command_not_found_handle tiene el mismo aspecto.

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
}

Respuesta:

Eso fue un error en bash , corregido en 4.4.

Si tiene definido el gancho command_not_found_handle() (que se invoca cuando no se encuentra un comando), bash pone en primer plano incluso si el comando no encontrado se inició en segundo plano.

Luego, dependiendo del tiempo, si el shell lee la línea de comando desde el dispositivo tty después de que command_not_found_handle fue puesto en primer plano, ese read() regresaría con un error EIO como sucede cuando un proceso en segundo plano lee desde un dispositivo terminal e ignora el SIGTTIN señal.

bash lo trataría como el final del archivo en la entrada del usuario como si hubiera presionado Ctrl + D

Uno puede reproducir el problema haciendo:

$ command_not_found_handle() { sleep 20; }
$ a &
$ x

Incluso si la primera read() tiene éxito porque se inició antes de que command_not_found_handle se coloque en primer plano, la segunda lectura y las siguientes después de presionar x fallarán y harán que el shell salga.

Con el command_not_found_handle predeterminado enviado en Ubuntu,

$ a & true &

También hace que el shell se cierre ya que el SIGCHLD al regresar true interrumpe el primer read() y hace que se inicie un segundo con el controlador aún ejecutándose en primer plano.

Sin embargo, en el caso general, parece poco probable que el error se active ya que el shell también se pone en primer plano antes de escribir su indicador, por lo que el command_not_found_handle tiene que ponerse en primer plano (hacer el tcsetpgrp() ) en el momento correcto (después del shell principal proceso se pone en primer plano y antes de que comience a leer desde el dispositivo tty).

Eso se solucionó en abril de 2015, con esta confirmación (entrada 4/23 en CWRU.log) después de un informe de un problema relacionado por Valentin Bajrami .