From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@euclid.skiles.gatech.edu>
Received: (qmail 18080 invoked from network); 9 Jan 1997 02:46:55 -0000
Received: from euclid.skiles.gatech.edu (list@130.207.146.50)
  by coral.primenet.com.au with SMTP; 9 Jan 1997 02:46:55 -0000
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id VAA12181; Wed, 8 Jan 1997 21:51:59 -0500 (EST)
Resent-Date: Wed, 8 Jan 1997 21:23:40 -0500 (EST)
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
Message-Id: <199701090219.DAA02248@hzoli.ppp.cs.elte.hu>
Subject: Re: Capturing "jobs" output.
To: chrisl@cybercom.net
Date: Thu, 9 Jan 1997 03:19:13 +0100 (MET)
Cc: zsh-users@math.gatech.edu
In-Reply-To: <199701082131.QAA07465@orion.cybercom.net> from Xris Laas at "Jan 8, 97 04:32:45 pm"
X-Mailer: ELM [version 2.4ME+ PL17 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"rq6l83.0.Eu2.hQ5ro"@euclid>
Resent-From: zsh-users@math.gatech.edu
X-Mailing-List: <zsh-users@math.gatech.edu> archive/latest/591
X-Loop: zsh-users@math.gatech.edu
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

> 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