Package: zsh
Version: 5.8-6+deb11u1
Severity: normal
zsh doesn't correctly set its idea of the current job if a job consists
of a shell function that got suspended after it was started. This is
the same condition that gives rise to Bug#1030606. In the example
below I'm using a zsh with the patch that I supplied for that bug.
In a zsh without that patch the bug still occurs in the same way, but
the job status reporting is messed up, making it more difficult to see
what's happening. Here's what the bug looks like:
% t0 () { sleep 1000; }
% t0
^Zzsh: suspended t0
% sleep 2000
^Z
zsh: suspended sleep 2000
% jobs
[1] - suspended (signal) t0
[3] + suspended sleep 2000
% fg %1
[1] - continued t0
^Zzsh: running t0
% jobs
[1] - running t0
[3] + suspended sleep 2000
%
Observe that in the final "jobs" listing the current job, marked with "+",
is the "sleep 2000" job, even though the job most recently active was the
"t0" job. By contrast, here's what correct job control looks like:
% sleep 1000
^Z
zsh: suspended sleep 1000
% sleep 2000
^Z
zsh: suspended sleep 2000
% jobs
[1] - suspended sleep 1000
[2] + suspended sleep 2000
% fg %1
[1] - continued sleep 1000
^Z
zsh: suspended sleep 1000
% jobs
[1] + suspended sleep 1000
[2] - suspended sleep 2000
%
Getting the current job wrong leads to the previous job (marked with "-")
also going wrong, and it generally impedes the use of these concepts
for efficient job control. I use the commands "fg" (foregrounding the
current job) and "%-" (foregrounding the previous job) all the time,
and I'm thus heavily affected by this bug.
-zefram
