From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24718 invoked by alias); 19 Apr 2012 04:27:16 -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: 30418 Received: (qmail 2636 invoked from network); 19 Apr 2012 04:27:11 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120418212700.ZM6913@torch.brasslantern.com> Date: Wed, 18 Apr 2012 21:27:00 -0700 In-reply-to: <1334792501-sup-5154@pimlott.net> Comments: In reply to Andrew Pimlott "Follow-up: CHECK_JOBS doesn't work when only one command was run since last Control-D" (Apr 18, 4:44pm) References: <1334792501-sup-5154@pimlott.net> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers , 303623-submitter@bugs.debian.org Subject: Re: Follow-up: CHECK_JOBS doesn't work when only one command was run since last Control-D MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Apr 18, 4:44pm, Andrew Pimlott wrote: } } Anyone care to take another stab at this old bug? } http://bugs.debian.org/303623 It looks like this behavior has been there since approximately the beginning of time. If there was ever an email thread about it, that thread pre-dates the zsh.org archives that date back to 1995. However, I think I found some clues, in particular a comment (still present in Src/jobs.c) that originated in an ancient version of the shell: /* If you immediately type "exit" after "jobs", this * * will prevent zexit from complaining about stopped jobs */ Keep in mind that two exits (or two ctrl+d) in a row are supposed to cause the shell to exit even if there are running jobs. In the years that intervened, code migrated to different files and the *other* place that sets stopmsg = 2 is now no longer in proximity to that comment. That other place is in the handler for ctrl+d. The rationale seems to be: 1. You type exit (or hit ^D) and the shell says you still have jobs. 2. You type "jobs" to find out what is still running. 3. There's nothing interesting in the jobs list (you just want them to die). 4. You type exit (or ^D) again. 5. Zsh deliberately ignores the fact that you ran a command between the two exits, and simply goes away without further complaint. All of this because someone else 17+ years ago was annoyed that the shell did NOT exit without complaining -- exactly the opposite of the thing that now annoys you. I *think*, if we no longer care to provide this particular (mis?)feature, that it would be OK to remove the "stopmsg = 2" from builtin.c:zexit(). However, I'm not entirely confident there aren't other side-effects.