From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26446 invoked by alias); 1 Dec 2009 03:57:52 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 27443 Received: (qmail 6346 invoked from network); 1 Dec 2009 03:57:40 -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=-1.9 required=5.0 tests=AWL,BAYES_00,PLING_QUERY autolearn=no version=3.2.5 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <091130185720.ZM3782@torch.brasslantern.com> Date: Mon, 30 Nov 2009 18:57:20 -0800 In-reply-to: <20091130183707.4f8ea36e@news01> Comments: In reply to Peter Stephenson "Re: unable to wait on completed job [was: should $! give the pid of subshell?]" (Nov 30, 6:37pm) References: <19213.26295.345572.732238@gargle.gargle.HOWL> <200911251748.nAPHmrCX010198@news01.csr.com> <091129211436.ZM1769@torch.brasslantern.com> <20091130183707.4f8ea36e@news01> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: unable to wait on completed job [was: should $! give the pid of subshell?] MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Nov 30, 6:37pm, Peter Stephenson wrote: } } If it's only an issue for $! (lastpid internally), I think it's fairly } straightforward to fix. I tried to make it work even if a new process } with the same PID came along later. This looks reasonable, but I wonder if we should make it conditional on POSIX_JOBS ? } No idea about anything to do with SIGTTOU, however, that's outside my } range. SIGTTOU is only a side-effect. The doc for POSIX_JOBS says: ... When the option is set, the MONITOR option and job control remain active in the subshell ... What's happening is that the subshell is not the tty process group leader, so when MONITOR tries to print the job number and PID (and later the exit status), the TTY driver stops it because it doesn't appear to be the foreground job. What's odder is that "stty -tostop" doesn't prevent this. Something is effectively reasserting that setting before the subshell gets going.