Re: Capturing "jobs" output.

[Zoltan Hidvegi <hzoli@cs.elte.hu>]

> I have noticed some unexpected behavior in the "jobs" builtin.  It is
> possible to redirect its output to a file, but any piping of any sort
> fails miserably.  Note these examples:
> 
> ---------------------------------
> % jobs
> [1]  + suspended (tty input)  cat
> [2]    running    sig-updater
> % jobs > foo.tmp
> % cat foo.tmp
> [1]  + suspended (tty input)  cat
> [2]    running    sig-updater
> % jobs | cat
> % echo $(jobs)
> % cat <(jobs)
> % cat =(jobs)
> ---------------------------------

Note that in all cases when jobs seemingly failed it was in a subshell.  A
subshell is created by fork() and it does not inherit child processes from its
parent so its job table is empty.  The only way to pass jobs output to a
process is using the

jobs > >(...)

syntax.  Unfortunately zsh does not wait for the >(...) process to terminate
which is probably a bug which will hopefully be fixed (together with some
other serious signal related bugs).

A simple pipe does not work since the left-hand side of a pipe is always
executed in a subshell in zsh.  In bash it is the right-hand side which is
executed in a subshell so jobs | cat works in bash but echo foo | read bar
does not set bar.  In ksh both jobs|cat and echo foo|read bar works.  I guess
that it first checks wether one of the pipe commands is not an external
command and it tries to execute the non-external side in the current shell.
That hack can be implemented in zsh (I think it would be very simple to add
this feature) but you can never rely on such thing in a portable script.
POSIX explicitely defines the behaviour unspecified here.

Zoltan