El "[email protected]" bit se expandirá a la lista de parámetros posicionales (generalmente los argumentos de la línea de comando), citados individualmente para evitar la división de palabras y la generación de nombres de archivo ("globbing").
El exec reemplazará el proceso actual con el proceso resultante de ejecutar su argumento.
En resumen, exec "[email protected]" ejecutará el comando dado por los parámetros de la línea de comando de tal manera que el proceso actual sea reemplazado por él (si el exec es capaz de ejecutar el comando).
Otras dos respuestas explican qué exec "[email protected]" lo hace. Esta respuesta en Stack Overflow explica por qué es importante para Docker y, como supones, tiene que ver con las señales:
Esto es importante en Docker para que las señales se transmitan correctamente. Por ejemplo, si Redis se inició sin exec , no recibirá un SIGTERM sobre docker stop y no tendrá la oportunidad de apagarse limpiamente. En algunos casos, esto puede provocar la pérdida de datos o procesos zombis.
Si inicia procesos secundarios (es decir, no usa exec ), el proceso principal se vuelve responsable de manejar y reenviar señales según corresponda. Esta es una de las razones por las que es mejor usar supervisord o similar cuando se ejecutan múltiples procesos en un contenedor, ya que reenviará las señales de manera apropiada.
"[email protected]" en shells tipo Bourne, en contextos de lista se expande a todos los parámetros posicionales como argumentos separados.
En un script, inicialmente, los parámetros posicionales son los argumentos que recibió el propio script.
exec es ejecutar un comando en el mismo proceso que el shell. Ese es el último comando que ejecutará un script porque después de eso, el proceso ejecutará otro comando además del shell.
Entonces, si su script es
#! /bin/sh -
exec "[email protected]"
Y llamas a tu script usando una línea de comando de shell como:
/path/to/your-script 'echo' "some test" 'x y'
Llamará a exec con echo , some test y x y como argumentos que ejecutarán echo (en la mayoría sh implementaciones, /bin/echo a diferencia del echo shell incorporado) en el mismo proceso que anteriormente estaba ejecutando el shell interpretando su script con some test y x y como argumentos.