From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29212 invoked from network); 26 Nov 2002 11:41:57 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 26 Nov 2002 11:41:57 -0000 Received: (qmail 2777 invoked by alias); 26 Nov 2002 11:41:32 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5525 Received: (qmail 2758 invoked from network); 26 Nov 2002 11:41:30 -0000 Date: Tue, 26 Nov 2002 12:42:22 +0100 From: Dominik Vogt To: zsh-users@sunsite.dk Subject: Re: why does "jobs | wc" not work? Message-ID: <20021126114222.GG1937@gmx.de> Reply-To: dominik.vogt@gmx.de Mail-Followup-To: zsh-users@sunsite.dk References: <20021126104930.GE1937@gmx.de> <18744.1038308955@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18744.1038308955@csr.com> User-Agent: Mutt/1.3.28i On Tue, Nov 26, 2002 at 11:09:15AM +0000, Peter Stephenson wrote: > Dominik Vogt wrote: > > There seems to be a strange bug with the jobs command in > > zsh-4.0.4. It seems that the output of the jobs command refuses > > to go into a pipe. > > This isn't strictly a bug, but there's a workaround in the 4.1 code. > > In zsh > > jobs | anything > > causes the shell to fork for the left hand side of the pipeline. Um, why must builtin commands run in a subshell? I would have naively thought commands like "echo something | ..." would just run in the current shell. Spawning a subshell sounds a bit inefficient. > This > is then no longer the shell with the job control, hence doesn't show any > jobs. Other shells fork the `anything' and run `jobs' in the current > shell. We deliberately don't do that because we like to be able to do > > anything | read foo > > to get the variable $foo set in the current shell (and all sorts of similar > examples). > > In 4.1, we use the obvious workaround: remember that we're in a subshell > of an interactive shell and keep a fossilized list of the jobs. Obvious, maybe, but it still sounds wrong in my ears. > This can > mean that the task list isn't up to date at the point where the jobs > command is actually run --- though there are obvious races when > background jobs terminate anyway, so I don't think that's a major > concern. Bye Dominik ^_^ ^_^