From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1986 invoked by alias); 7 Feb 2010 22:36:58 -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: 27685 Received: (qmail 24763 invoked from network); 7 Feb 2010 22:36:56 -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-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <100207143647.ZM9122@torch.brasslantern.com> Date: Sun, 07 Feb 2010 14:36:47 -0800 In-reply-to: <201002072134.o17LYj66005365@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: have '&' automatically disown?" (Feb 7, 9:34pm) References: <201002072134.o17LYj66005365@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: have '&' automatically disown? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 7, 9:34pm, Peter Stephenson wrote: } Subject: Re: have '&' automatically disown? } } Greg Klanderman wrote: } > Would it make sense to just auto-disown when monitor is off? } } That *does* make a lot of sense, actually: if job control's turned off, } there's no point in half-pretending it isn't. Disowning existing } background jobs at that point at least makes more sense than having them } come back in a zombified fashion. I'll think about it tomorrow. Disowning a job makes it immune to HUP signals, etc. That's not what nomonitor is for -- turning off monitor is supposed to make zsh act like the old Bourne shell, where jobs still "belonged" to the shell and would be HUP'd if the terminal connection dropped, but the shell had no way move them between background and foreground. The reason you seem to hang the shell when foregrounding a job that was started with monitor turned off, is because jobs started without monitoring must be immune to keyboard signals other than hangup. The shell is not really hung, but once the process has been forked the shell has no way to tell it to change its SIGINT/SIGTSTP behavior to go back to being interruptible/stoppable.