Backs out part of 188c5cd5 (workers/50874). With this change, after a
new subshell is forked upon suspend of the right side of a pipeline, the
previous foreground subjob is resumed first and the new subshell remains
stopped until that job finishes.
Reverts 15bf8ace (workers/50134). Thanks to Jun T. for debugging assistance.
Issues came down to two things:
1. update_job() may be called on a process group leader even when a
signal was NOT sent to any process in that process group. This
caused jobs to be resumed or backgrounded incorrectly or in the
wrong order.
2. When there is a current-shell complex command (in braces) on the
right side of a pipeline, external processes within it have their
own process groups, but a tty signal sent to such a process should
be treated as if received by the whole complex command.
This fixes:
* Suspend/resume of a foreground pipeline within a shell function
* Interrupt or suspend/resume of processes in a pipeline ending in { ... }
* Interrupt of such a pipeline after exit of the last process in { ... }
These affected interactive shells only (MONITOR set plus tty signals).
In some cases the process group leader of the forked-left side of a
pipe needs to be set to the pipe process PID rather than to the group
leader PID returned by entersubsh().
Don't attempt to query invalid job off end of table, resulting in
crashes from $jobtstates.
If background task started in subshell, look at tatsks within subshell
instead of main shell. Document and add test.
If we use kill to test for continued existence of a process group,
we should check on failure that the error is ESRCH, as EPERM
indicates the group still has memebers but running privileged
so should be left alone.
The following case was encountered in the wild:
% zsh; echo "$?"
% trap 'exit 5' TERM
% kill ''
5
This behaviour seems more likely to be the result of bugs in programs
(e.g. `kill -9 "$unsetvar") rather than being desirable
behaviour to me. It also seems unintentional judging by the code and
documentation, since it comes about as a result of the fact that:
- `isanum` returns true for empty strings (since an empty string
technically only consists of digits and minuses...);
- `atoi`, when passed a pointer to an invalid number, returns 0;
- `kill(0, signal)` sends the signal in question to all processes in the
current process group.
There are (at least) two ways to solve this issue:
1. Add special handling to `kill` to avoid this case. See this patch[0]
for a version that does that.
2. Change how isanum behaves. Since the only two call sites that use it
both seem like they should handle the case where the input char array
is empty, that seems like a reasonable overall change to me.[1]
After this patch:
% trap 'exit 5' TERM
% kill ''
kill: illegal pid:
The regression test for `kill` without a sigspec is also included in
this commit, as previously it's not possible to test it trivially as it
would still kill the test runner in expected-to-fail mode; see
discussion in workers/45449.
0: workers/45426: https://www.zsh.org/mla/workers/2020/msg00251.html
1: The other call site using isanum() is the fg builtin, but in that
case we just fail later since we can't find any job named '', so no
big deal either way. It's the kill case which is more concerning.
If we can't grab the terminal in interactive mode, give
up after 100 goes. This is a completely arbitrary choice;
we simply don't know what in the system could change the
result of looping further.
Be more consistent about marking both superjob and subjob as
running when sending SIGCONT.
Send SIGCONT to superjob / subjob combination any time it is put
in foreground, even if thought running, since subjob may invisibly
have suspended.
When waiting for superjob, wait for subjob, too.
If list_pipe_job triggered more than once we need to know
the most recent process group leader, so record that
both if the attach happened in the main shell on in
entersubsh().
Also don't pass back proocess group for ESUB_ASYNC subshells.
A newly forked subshell now reports back the process group it
will be using for the main shell to record.
This prevents an error where the shell incorrectly thought an
exiting process owned the terminal and so grabbed it back,
putting the foreground process into the background.
Background jobs that had just exited could still be in
the table when the process had already finished and the
status was recorded, causing the wrong status to be reported.
This is a job forked from the current shell when a job partly
running from the current shell was suspended. When all associated
processes started from the main shell are finished the job is
continued and at this point the disown can complete.
When shell is forked to run right hand side of pipieline it should
use its own PID as process group if the left hand side of the
pipeline has already exited.
If the child's resisdent set size in megabytes exceeds this, print
out the resource (TIMEFMT) string. Document you need to add memory
usage to this by hand.
Oliver Kiddle