With zsh running as the current shell of a terminal, with one or several sub-process jobs running ‘under’ that zsh shell, executing exec zsh from that shell kills all running background jobs.
Is this expected? Does that mean that someone should never execute exec zsh when the zsh shell has unfinished sub-process/background jobs running? Or is there something that can be done/configured to prevent that behaviour?
In a (sourced) script it would always be possible to check if there are any jobs running, and interactively one could print the number of running jobs in the zsh prompt to make the user aware. Are these the only possibilities?
>Solution :
The premise is false: exec zsh doesn’t kill background jobs.
However, job control is tracked inside the shell’s memory, not provided by a call to the OS, so when you use exec zsh to replace the shell with a new instance (inheriting the old shell’s process table entry, file descriptors and environment variables but losing most other state), that new instance doesn’t know about jobs the old shell created.
Use tools like ps when you need to see previously-created background tasks whether or not your shell’s job control is aware of them.
> sleep 60 & echo $!; exec zsh
[1] 33264
33264
> ps | grep 33264
33264 ttys002 0:00.01 sleep 60
33267 ttys002 0:00.00 grep 33264