From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26481 invoked from network); 14 Mar 2009 16:59:42 -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 news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 14 Mar 2009 16:59:42 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 4905 invoked from network); 14 Mar 2009 16:57:16 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Mar 2009 16:57:16 -0000 Received: (qmail 1278 invoked by alias); 14 Mar 2009 16:56:48 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13906 Received: (qmail 1262 invoked from network); 14 Mar 2009 16:56:48 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 14 Mar 2009 16:56:48 -0000 Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by bifrost.dotsrc.org (Postfix) with ESMTP id 3BD2A80307F8 for ; Sat, 14 Mar 2009 17:56:43 +0100 (CET) Received: from torch.brasslantern.com ([96.249.201.13]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KGI001JB9QIV5X6@vms173001.mailsrvcs.net> for zsh-users@sunsite.dk; Sat, 14 Mar 2009 11:56:43 -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 n2EGufJl012281 for ; Sat, 14 Mar 2009 09:56:41 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n2EGueC6012280 for zsh-users@sunsite.dk; Sat, 14 Mar 2009 09:56:40 -0700 From: Bart Schaefer Message-id: <090314095640.ZM12279@torch.brasslantern.com> Date: Sat, 14 Mar 2009 09:56:40 -0700 In-reply-to: <20090314083421.78414.qmail@smasher.org> Comments: In reply to Atom Smasher "weird behavior with "[un]setopt monitor"" (Mar 14, 9:34pm) References: <20090314083421.78414.qmail@smasher.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@sunsite.dk Subject: Re: weird behavior with "[un]setopt monitor" MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.92.1/9107/Sat Mar 14 06:25:15 2009 on bifrost X-Virus-Status: Clean On Mar 14, 9:34pm, Atom Smasher wrote: } } somewhat as expected: } % unsetopt monitor ; sleep 30 & ; setopt monitor } % jobs } [1] + running sleep 30 } % kill %sleep } kill: kill %sleep failed: no such process No, that's definitely not as expected. The kill should have succeeded. } not at all expected: } % unsetopt monitor ; sleep 30 & ; setopt monitor } % jobs } [1] + running sleep 30 } % unsetopt monitor ; kill %sleep } % jobs This, however, IS as expected. } in the second case, i start "sleep 30" in the background after unsetting } the monitor option. after the job is dropped into the background, i reset } the monitor option. the job is listed in the jobs table, which i didn't } expect. Jobs started with monitor turned off have always been in the job table, because they have to be properly managed by the shell for purposes of the "wait" command etc. even if you can't manipulate them with "fg" and "bg". Older zsh hid them from view, but would then lose track of details like the job name, so when you turned monitor back on again "jobs" would find them and produce a list of nameless processes. There are still some oddities. I don't recall exactly when jobs started to be visible to "jobs" even with monitor turned off, but if they are started when monitor is off they're impervious to ctrl+z (TSTP signals), so if you turn monitor on again and bring them into the foreground, they can't be stopped and re-backgrounded. } as expected, it isn't killed in the normal way. This is a bug. Once you turn "monitor" back on, "kill" attempts to hit jobs with killpg(pid, sig), equivalent to kill(-pid, sig), but because the job was started with monitor turned off, it has no process group and consequently killpg() fails even though the pid exists. } the third example is where things really get weird. i start "sleep 30" in } the background after unsetting the monitor option. after the job is } dropped into the background, i reset the monitor option. the job is listed } in the jobs table, which i didn't expect. so far, the same as the second } example. but if after i unset the monitor option, i can kill the job with } kill. not at all what i expected. With monitor off, zsh does kill(pid, sig) directly to stop only the single process, regardless of whether the jobs were started with the option turned on, so the right thing happens for jobs started without monitor, but the wrong thing happens for jobs started with monitor. This probably needs some attention; "kill" should do its work based on the state of "monitor" at the time the job table entry was created, not on the current state. Bottom line, you're not guaranteed of predictable behavior unless you change the monitor option only when the job table is empty. } is this a bug or an undocumented feature? It's a bug, but not the bug you think. } it seems like an alternate table } to store jobs in, which is useful. I'm not sure how you reached that conclusion, but it all depends on whether the jobs are assigned to a process group. Jobs started with monitor off are never expected to have interaction with a terminal, so they get no process group and ignore tty-generated signals. All jobs are in the same table, regardless. It could be considered a bug that "fg" fails to ignore jobs that do not have a process group.