Open caseman opened 3 years ago
What I have learned so far:
Inverting the check if (!priv->child) {
above alone causes the job to exit if you send the worker process (e.g., sleep) SIGSTOP. You can prevent this by not returning here if priv-child
is true:
https://github.com/emersion/mrsh/blob/280fdf5ec59d6e66541d6b90e93ad0a3866b58ee/shell/job.c#L250
The job still does not report its status properly though if you send SIGSTOP to sleep because the sleep (grand)child process itself is not tracked in the job (edit: it is added, but presumably that happens inside the background child, so it isn't actually tracked). However simply tracking it would not help because the job reports "running" if any of its child processes are running, and the main job process (child of mrsh, parent of sleep worker) is always running.
I'm assuming the intermediate job process is a simplification somehow, other shells like zsh don't use one. But regardless of that it doesn't seem useful to report the job status based on the status of that process, other than when it exits entirely perhaps. I'll keep exploring.
The problem seems to be here: https://github.com/emersion/mrsh/blob/280fdf5ec59d6e66541d6b90e93ad0a3866b58ee/shell/job.c#L228
This check doesn't make sense to me, I would think you would only want to check
WUNTRACED
for children, since checking it for the parent shell process seems useless, but maybe I'm missing something. Also in order to detect SIGCONT the optionWCONTINUED
would need to be used where available, something like:Although maybe that check is too pedantic, I'm not sure if any major platforms lack support for
WCONTINUED
today.Happy to make a PR but I feel like I don't understand the intention of the check unless
priv->child
is supposed to mean something different than I'm thinking, is it only supposed to be set for grandchildren?