From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18194 invoked from network); 9 Jul 2009 21:40:52 -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.6 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; 9 Jul 2009 21:40:52 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 4457 invoked from network); 9 Jul 2009 21:40:44 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 9 Jul 2009 21:40:44 -0000 Received: (qmail 24516 invoked by alias); 9 Jul 2009 21:40:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 27114 Received: (qmail 24483 invoked from network); 9 Jul 2009 21:40:33 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 9 Jul 2009 21:40:33 -0000 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by bifrost.dotsrc.org (Postfix) with ESMTPS id A238A80307FA for ; Thu, 9 Jul 2009 23:40:30 +0200 (CEST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MP1Ly-0004ny-5O for zsh-workers@sunsite.dk; Thu, 09 Jul 2009 21:40:30 +0000 Received: from l3-128-170-36-102.l-3com.com ([128.170.36.102]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Jul 2009 21:40:30 +0000 Received: from ebb9 by l3-128-170-36-102.l-3com.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Jul 2009 21:40:30 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: zsh-workers@sunsite.dk From: Eric Blake Subject: Re: non-interactive set -m Date: Thu, 9 Jul 2009 21:40:19 +0000 (UTC) Message-ID: References: <200907080858.n688wXfc030608@news01.csr.com> <200907081349.n68DneSv001850@news01.csr.com> <20090709212345.05cc2213@pws-pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 128.170.36.102 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)) Sender: news X-Virus-Scanned: ClamAV 0.94.2/9551/Thu Jul 9 15:22:08 2009 on bifrost X-Virus-Status: Clean Peter Stephenson ntlworld.com> writes: > > It looks like the fg activated the sleep process, because it took five > > seconds for the Stopped message to appear, but fg failed to print to stdout > > the process that it just activated. > > ... and the third part: this seems to be another question of testing if > MONITOR is set (jobbing---I wish we didn't those #define's) but not if > INTERACTIVE is set (interact). Also need to fix up the output to go to > stderr instead of the file (not) opened to the terminal. POSIX states that fg output goes to stdout, not stderr. Thus, I should have a silent wait for 5 seconds with the following command; although with this latest round of patches, things are still noisy: $ Src/zsh -c 'set -m; sleep 5& fg >/dev/null' [1] 5804 [1] + running sleep 5 $ It looks like two different sources of noise - creating the background task is outputting information about the job just created, which should really be conditional on being interactive (a non-interactive shell will use 'jobs' to learn this information, rather than having it printed to stderr). The other source of noise is that fg is writing to stderr instead of the required stdout. Also, POSIX states that fg output should be the name of the command that was brought into the foreground, and not the 'jobs' output describing that command. Notice how bash does it: $ bash -ci 'set -m; sleep 5& fg >/dev/null' [1] 21428 $ bash -c 'set -m; sleep 5& fg' sleep 5 $ bash -c 'set -m; sleep 5& fg >/dev/null' $ > I've done the same thing at another point, where the status of a job > changes. You're the guinea pig so if you think this output should or > shouldn't be there I can leave it or change it. Not a problem - I'm actually having fun trying to test this. At any rate, given my (lack of) familiarity with the zsh code layout, reporting my tests is easier than trying to propose patches, although I'll do what I can. -- Eric Blake