On 28/02/2022 23:20, Robert Elz via austin-group-l at The Open Group wrote:
It is worth pointing out though that testing this in interactive shells
is somewhat of a weird case - it should probably be done in a script
instead. That's because of the effect of the (implicit) jobs command
before each PS1 output, that should have reported the background job as
stopped when the Ctl-Z was sent, before the wait command is issued.
I know, that was intentional for two reasons.
1: Multiple shells turn out to have logic that amounts to roughly
while (job->state == RUNNING) {
wait(job->pid);
/* ... */
}
where a simpler test leaves job->state as RUNNING even though the job
has stopped already, simply because the shell has not yet picked up on
the state change, and so the shell actually does end up waiting for the
stopped job. Sort of, anyway. I did not want to complicate the test with
such matters.
2: Sending SIGCONT from another process could well be a wrong thing to
do. An interactive shell is responsible for switching the TTY
foreground process group as jobs are started, stopped, resumed. A
SIGCONT from another process would just send SIGCONT, nothing else, as
if the job was resumed by the bg command. Given that the child process
would have been resumed and the shell would be waiting for that child
process to finish, resuming as if by the fg command would likely be more
appropriate, but that is not something an external process is capable of
doing, that is something only the shell itself can do.
Thanks all for the answers, all. If this is something where the standard
says shells must behave one way, but it remains unclear whether it says
so intentionally and there may be good reasons why implementations
don't, I will need to think carefully about what to do in my shell.
Cheers,
Harald van Dijk
