Trabajos en segundo plano en scripts de shell

Tengo un script de shell script.shcon un comando cmdiniciado en segundo plano, es decir:

#!/bin/bash
…
cmd &
…

Si abro un emulador de terminal (he intentado xfce4-terminal y gnome-terminal) y ejecuto script.shdentro, mi comando cmdse ejecuta efectivamente y se ejecuta en segundo plano, como se esperaba.

Pero, si abro un emulador de terminal del anterior (o al comienzo de mi sesión de escritorio, que es mi caso de uso real), y ejecuto mi script por

xfce4-terminal -H -x script.sh (or gnome-terminal -x script.sh)

el comando cmdya no se ejecuta.

Descubrí que puedo forzar que se ejecute al agregar set -mmi script, pero no entiendo por qué es necesario (ni suficiente, en realidad) en este caso, y no en el anterior. De hecho, si pongo un set -oen mi script, obtengo el mismo resultado en ambos casos.

¿Alguien puede explicarme esto y / o decirme la forma correcta de proceder con trabajos en segundo plano en scripts de shell? ¡Gracias!

EDITAR: En realidad, cmdse ejecuta en ambos casos, pero en el segundo, se elimina inmediatamente por la terminación de script.sh. Para evitar esto, uno puede usar nohup, pero no es suficiente, y es lo más extraño para mí: uno también tiene que poner sleep 1, o algo así, para permitir que el proceso se inicie correctamente en segundo plano y se disocie del shell principal, de lo contrario también se mata.

Realmente no entiendo esta diferencia de comportamiento entre los dos shells, ya que ambos no son interactivos, como se indicó en un comentario anterior.

Si abre xfce4-trminalo gnome-terminal(u otro terminal) Su shell está en modo interactivo. Cada script se ejecuta en modo interactivo.

Si corres script.shpor

xfce4-terminal -H -x script.sh

o

gnome-terminal -x script.sh

u otro terminal, su shell está en modo no interactivo.

Los scripts pueden verse obligados a ejecutarse en modo interactivo con la -iopción o con un #!/bin/bash -iencabezado. Tenga en cuenta que esto puede causar un comportamiento errático de la secuencia de comandos o mostrar mensajes de error incluso cuando no haya ningún error.

¿Qué es set -m? Es el modo monitor . Los procesos en segundo plano se ejecutan en un grupo de procesos separado y una línea que contiene su estado de salida se imprime al finalizar. Está habilitado de forma predeterminada para shells interactivos.

¿Qué es set -o? Es escribir la configuración actual de las opciones en la salida estándar en un formato no especificado.

¿Por qué set -ofunciona?

La opción −o se adoptó de KornShell para abordar las necesidades del usuario. Además de su interfaz amigable en general, −o es necesario para proporcionar el modo de edición de línea de comando vi, para el cual la práctica histórica no produce un nombre de opción de letra única. (Aunque podría haber sido posible inventar dicha letra, se reconoció que se desarrollarían otros modos de edición y -o proporciona un amplio espacio de nombres para describir tales extensiones).

Las implementaciones históricas son inconsistentes en el formato utilizado para el informe de estado de la opción -o. Se agregó el formato + o sin un argumento de opción para permitir el acceso portátil a las opciones que se pueden guardar y luego restaurar usando, por ejemplo, un script de puntos.

De todos modos, set -mes la forma preferida.

La pregunta ha sido respondida en Unix Stackexchange (ver también comentarios adicionales debajo de la respuesta). Se trata de quién envía la señal SIGHUP a quién y cuándo. Y una alternativa a set -m / set +malrededor cmd &de script.shes trap '' HUP / trap - HUP.