Los programas no aparecen en los trabajos si los inicio en segundo plano con un script de shell

Quiero iniciar tres programas (2x streamlit, 1x python) en segundo plano con un script de shell:

#!/bin/sh
cd /Users/mc/src/crypto/ || exit
streamlit run dashboard.py &
streamlit run dashboard_basis_viewer.py &
/Users/mc/.virtualenvs/crypto/bin/python basis_calculator.py &

Este script funciona (es decir, los programas se inician bien) pero hay dos problemas:

  1. Ninguno de los procesos aparece bajo el jobscomando.
  2. Si cierro la terminal (iTerm), todos esos procesos aún se están ejecutando

Si ejecuto las últimas 3 líneas manualmente desde la línea de comando, no tengo ninguno de esos problemas. ¿Que está pasando aqui? ¿Cómo puedo arreglarlo?

El script hace exactamente lo que escribe en la primera línea, no estoy seguro de cuál es su pregunta aquí. ¿Qué quiere lograr al final (o, en otras palabras, qué es exactamente lo que necesita arreglarse y cómo debería verse/comportarse)?
@nohillside Creo que los procesos que lanzo deberían aparecer debajo jobsy los procesos deberían eliminarse si salgo de la terminal. Esos son los comportamientos si inicié los procesos en la línea de comandos en lugar de hacerlo desde un script.
AFAIK jobsno muestra los procesos en segundo plano iniciados desde scripts (solo aquellos que inició de forma interactiva en el shell actual).
En lugar de ingresar ./myscript, intente source ./myscripto . ./myscript.

Respuestas (1)

¿Que está pasando aqui?

Tiene un proceso que ejecuta un shell. Según la información proporcionada en la pregunta publicada, se supone que se trata de un zsh, pero es posible que haya otros. Cuando se ejecuta el script publicado, se crea un nuevo proceso para ejecutar el script en un archivo /bin/sh. Este nuevo proceso inicia tres nuevos trabajos en segundo plano asociados con el archivo /bin/sh. Luego /bin/shfinaliza, dejando los tres trabajos como procesos huérfanos. Entonces, cuando jobsse ingresa el comando, los tres trabajos no aparecen, porque los tres procesos ahora huérfanos nunca fueron trabajos del original zsh. Además, cuando zshtermina, no se envían señales de tipo de terminación a los tres trabajos porque los procesos son huérfanos.

¿Cómo puedo arreglarlo?

Si es necesario que aparezcan los tres trabajos cuando jobsse ingresa el comando, entonces un comando .o sourcepuede preceder a la ruta y el nombre del script. El script se ejecutará en el actual zshy, por lo tanto, se ignorará la primera línea del script publicado. Por ejemplo, si el nombre de la secuencia de comandos es myscripty está en el directorio de trabajo actual, se podría ingresar cualquiera de los siguientes.

. ./myscript
source ./myscript 

Si es necesario, no es necesario que aparezcan los tres trabajos cuando jobsse ingresa el comando, luego se puede agregar una línea que contenga el waitcomando al script publicado. Esto evitará que se creen huérfanos cuando se utilice lo siguiente para ejecutar el script en segundo plano.

./myscript &

Finalmente, la idea de un script podría abandonarse en favor de una función. A continuación se muestra un ejemplo.

myfunction()
{
    local "cwd=$(pwd)"
    cd /Users/mc/src/crypto/
    local "n=$?"
    if [[ n -eq 0 ]]; then 
        streamlit run dashboard.py &
        streamlit run dashboard_basis_viewer.py &
        /Users/mc/.virtualenvs/crypto/bin/python basis_calculator.py &
        n="$?"
    fi
    cd "$cwd"
    return "$n"
}

 

Fantástica respuesta. Aunque, si puedo hacer una breve pregunta para aclarar... sé que ambos .y sourcetienen el mismo resultado... pero solo la mayor parte del tiempo, al menos en mi sistema en mi experiencia. Si intento obtener una secuencia de comandos utilizando el .alias de una subcapa dentro de otra secuencia de comandos, falla. Solo sourcefunciona el comando. Siempre supuse que esto se debía a que el alias no se había establecido en un alcance global y la subcapa no cargaba mi .bash_profile / .bashrc / etc. pero al leer su respuesta, me di cuenta de que solo estaba asumiendo que todos estos años. ¿Estoy cerca?