Re: `jobs' builtin does not work with pipe in scripts

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 26,  9:16pm, ZyX wrote:
}
} Reply to message «Re: `jobs' builtin does not work with pipe in scripts», 
} sent 20:47:39 26 November 2010, Friday
} by Bart Schaefer:
} 
} What is your version of zsh?

I tested using the latest from CVS:

Src/zsh -fc 'print $ZSH_VERSION $ZSH_PATCHLEVEL'
4.3.10-dev-2 1.5130

However, I just also tried 4.2.0 and although -omonitor does not work,
setopt monitor appears to; with the caveat that "jobs -p | ..." caused
the shell to hang, but "... <(jobs -p)" worked.

Hmm, previously you reported yours as "zsh-4.3.10-r2" but I can't find
evidence that this was ever an official zsh version number.  There were
a bunch of changes to the handling of MONITOR in July 2009, which is a
bit after 4.3.10 was released.  That's also around the time that the
POSIX_JOBS option was added, and is the last time job control was being
changed in any noticeable way.

} It does not work for me:
}     (zyx:~) % zsh -fc 'setopt monitor;sleep 3 & fg'
}     zsh:setopt:1: can't change option: monitor

That should only happen if the shell has no terminal, and can't get one
e.g. by opening /dev/tty.  (I'm not sure that a terminal should still
a requirement for MONITOR given its other evolution.)

} And if zsh does not provide job control without this option, why
} `jobs' works as expected without pipe?

It's a question of whether the "jobs" command is running in a forked
subshell or not.  Subshells are incapable of manipulating the jobs
created by their parent, so normally the job table is emptied just
after forking when a subshell is begun.  Zsh forks the left side of
pipelines, so in "jobs | ..." there are no jobs to print.

A special trick was put in place back in 2002 to allow the parent's
job table to hang around specifically for the "jobs" command to be
able to peek at it, but that read-only copy is only maintained when
the MONITOR option is on.  (That may again be an obsolete detail.)

However, depending on what you want to do with the output, there are
two other ways to go about this.  One is to use the $jobstates hash
from the zsh/parameter module, which maps job numbers to strings that
describe the state.  Another is to use "jobs -p >>(...)" to keep the
jobs command in the foreground shell and manipulate its output in a
subshell.  An third is to direct output from jobs into a file, then
read the file.