zsh 4.0.2 bug: jobs pipes no output

zsh 4.0.2 bug: jobs pipes no output

[Troy Bridoux]

Debian Linux 3.0

% jobs
[1]  + suspended  vim

% jobs | cat


As you can see, "jobs"s standard output gives nothing to "cat"

Re: zsh 4.0.2 bug: jobs pipes no output

[Bart Schaefer]

On Oct 22,  3:46pm, Troy Bridoux wrote:
} Subject: zsh 4.0.2 bug: jobs pipes no output

Minor point, but 4.0.2 is two years (five revisions) out of date.

} As you can see, "jobs"s standard output gives nothing to "cat"

This is intentional behavior, not a bug.  However, it's been a point
of confusion for long enough that it was "fixed" about 15 months ago
in development versions of zsh (4.1.x).

It's intentional in that zsh forks off the left side of pipelines and
tries to keep the right side in the current shell, whereas nearly all
other shells either always fork both sides of a pipeline, or fork the
right side.  Without going into the reasons why forking left first is
preferable, this means that when a builtin is on the left, it is run
in a subshell -- and subshells do not have job control, and therefore
have no jobs to list.

The "fix" for this was to allow the subshell to retain part of the job
table information from the parent, and print it out -- but it means
there can be race conditions, so that the output from "jobs" on the
left side of a pipe may be incorrect with respect to the actual list
of jobs being managed by the parent.  For example:

zagzig% echo $ZSH_VERSION
4.1.1-dev-1
zagzig% sleep 20 &
[1] 5850
zagzig% (sleep 30; jobs) | cat
[1]  + done       sleep 20
[1]  + running    sleep 20
zagzig% 

Whether it's better to have the job list be incorrect or unavailable
remains a matter of philosophical debate.  I'm beginning to think I
prefer "unavailable."