From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7704 invoked from network); 12 Jul 2009 18:29:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from new-brage.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.254.104) by ns1.primenet.com.au with SMTP; 12 Jul 2009 18:29:07 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 35766 invoked from network); 12 Jul 2009 18:28:53 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 12 Jul 2009 18:28:53 -0000 Received: (qmail 10376 invoked by alias); 12 Jul 2009 18:28:39 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 27138 Received: (qmail 10343 invoked from network); 12 Jul 2009 18:28:38 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 12 Jul 2009 18:28:38 -0000 Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by bifrost.dotsrc.org (Postfix) with ESMTP id A541E8027106 for ; Sun, 12 Jul 2009 20:28:34 +0200 (CEST) Received: from torch.brasslantern.com ([96.238.220.32]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KMO002QLLYRY6B0@vms173007.mailsrvcs.net> for zsh-workers@sunsite.dk; Sun, 12 Jul 2009 13:28:04 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n6CIS2E5014391 for ; Sun, 12 Jul 2009 11:28:03 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n6CIS1xB014390 for zsh-workers@sunsite.dk; Sun, 12 Jul 2009 11:28:01 -0700 From: Bart Schaefer Message-id: <090712112801.ZM14389@torch.brasslantern.com> Date: Sun, 12 Jul 2009 11:28:01 -0700 In-reply-to: <20090712160156.265f294b@pws-pc> Comments: In reply to Peter Stephenson "Re: non-interactive set -m" (Jul 12, 4:01pm) References: <200907111905.n6BJ54oS026712@pws-pc.ntlworld.com> <20090712160156.265f294b@pws-pc> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk Subject: Re: non-interactive set -m MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9556/Sun Jul 12 17:03:47 2009 on bifrost X-Virus-Status: Clean On Jul 12, 4:01pm, Peter Stephenson wrote: } } This looks to me like quite a big change in the way background processes } from subshells work, but if it's what POSIX users expects that's } fine---I'm not expecting anyone to turn the option on just for fun. If zsh was previously in the wrong here, then so is pdksh: schaefer[507] ksh 4.2.0 $ sleep 30 & [1] 14322 $ (jobs) [1] + Running sleep 30 $ jobs | head [1] + Running sleep 30 $ (wait) $ (fg) ksh: fg: job control not enabled $ [1] + Done sleep 30 Now, in pdksh "jobs | head" the "jobs" command is in the foreground shell and "head" is forked off, whereas in zsh both "jobs" and "head" will have been forked because of handling of this case ... $ jobs | read line $ echo $line $ jobs | { read line; echo $line;} [1] + Running sleep 30 $ ... where in zsh the first "echo $line" will work (but won't any more with this patch and POSIX_JOBS set). POSIX doesn't specify whether the left or right side of a pipeline will run in the current shell, which means that with POSIX_JOBS set and this patch applied zsh will produce different results for the piping of "jobs" to something. Since it's only been about a year (?) since we went through all the rigamarole of making "jobs" in a sub- shell have access to (a snapshot of) the parent's job table, it seems hasty to break that again even an as option. Also look here: $ sleep 30 & [1] 14341 $ ( sleep 40 & jobs ) [2] + Running sleep 40 [1] - Running sleep 30 $ Note that in pdksh the job in the subshell is added to the table of jobs inherited from the parent shell (testing with pdksh 5.2.14). This may be something we should ask about on the austin-group list before we select an interpretation and implement it. I'm currently not able to post there because of some problem with the listserv's interpretation of the "+" in the email address I used to sign up.