From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89 invoked by alias); 24 Jun 2017 19:02:20 -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: 41356 Received: (qmail 16337 invoked from network); 24 Jun 2017 19:02:20 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f49.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.213.49):SA:0(-0.0/5.0):. Processed in 1.231832 secs); 24 Jun 2017 19:02:20 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.49 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject:cc :mime-version; bh=aYGN4lC/de667N2MycTGxcRWvcGSwE9cH3ZHRRLPq+s=; b=FZQieA+Ftz3SoG3u9PHoK+VxsGAe2WE8uED5OJnFAI/OXFtABMnK6aC3O7ZSQ6tsKO JLwsXA3JaeLWBujq8RU9b+ZDlTzL6w0oD98nYRooCjMdrJmT1LzQHFLBa4RofJiYUbU9 xPyZ2vHLiCJ7b67C/S2QH59qk4yGfyY6vdHou9H/kjoL4xnaGEg24FSSmZfwNxSKdMAr +caNE2cp9UTaUBSiFahhlJpoLBIIRULewGPkBFXgwHSJABLUgyZ7Q9gFkQZPWOhzycL3 xEo4TBGKUZg8yHTVSszF5bwy/6XjB7X8+CIsL/jNsxYTDT+ofyw2gzab6KZV8d69TXzF ypUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:cc:mime-version; bh=aYGN4lC/de667N2MycTGxcRWvcGSwE9cH3ZHRRLPq+s=; b=HME+ZIR8pkI3UbWy6+hYLT4duM9GHqQKLLvyD5WXe0zFgOicQH8vj781mEx+t1nkae kgaDpbAww1wRxsE5iwq8ZwPk7kI2Ma11OK3W5ucdfTPRluDZv7834bxA/G1Hc0deeBIg KBW9UTrjfaO8eIQW73dQxdpbB9d25dLzT71Dy0NSVGzH1+SA8uu+fydTAuXnwdM2mmWS HAHFX7dn/yGWfUbenEBMbvyu5yvmoUEOv6NFqi0m3J/7oLPoi/R52wbwAudd8vrZ7Rvu Cl5hmko+4V/yrGj/oPobvuVVIMCfOUBA3YzxZmT8ym2p9vobN8q0zxx4GHp57apAFHG+ t7ww== X-Gm-Message-State: AKS2vOyLaTM84Qqqgvok7S7jEkzjOJhhm29YjqWZ1ca7c+Fk4xlKeNPJ 3g9lybqyHSC2Wc/NyIo= X-Received: by 10.31.170.22 with SMTP id t22mr3705095vke.100.1498330932406; Sat, 24 Jun 2017 12:02:12 -0700 (PDT) From: Bart Schaefer Message-Id: <170624120310.ZM30935@torch.brasslantern.com> Date: Sat, 24 Jun 2017 12:03:10 -0700 In-Reply-To: Comments: In reply to Mikael Magnusson "interrupt handling bug (again?)" (Jun 6, 9:08pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh workers Subject: Re: interrupt handling bug (again?) Cc: Mikael Magnusson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 6, 9:08pm, Mikael Magnusson wrote: } } % for a in 1 2 3; do xterm; done } then hit ctrl-z in that term and bg it, do stuff and at some point hit } ctrl-c, the backgrounded for loop will be interrupted I'm not 100% sure but this is most likely a TTY process group issue. If I change "xterm" to % for a in 1 2 3; do; sleep 10; echo $a; done then I can reproduce the behavior on "bg". However, if I stop, bg, *and* disown, I end up with the sleep resumed, but the subshell that handles the loop is still stopped. Which is an entirely different but related bug. } This happens even if you disown it, but not if } you run it with & or &|. Here's what I think is going on: When you run with & or &|, it's known "up front" that the job will be in the background, so the entire loop is immediately disconnected from the terminal and with &! also discarded from the job table. If instead you start in the foreground, the loop is in the parent shell, so by definition is attached to the terminal. This is very important because it means that "xterm" (or in my case "sleep") is the foreground job. When you ^Z, that suspends the foreground job. The parent zsh gets a wait-status of stopped, but it knows it's in a loop, so it forks and also suspends the new subshell to be able to keep the loop state without suspending the parent. This is where things get weird. When you "bg" that only resumes the previous foreground job, it does not resume the forked subshell (if it did, the next command in the loop would immediately start). That means the loop-subhell is still in the job table. It stays there (still stopped) until the previous foreground job finishes, at which point the parent continues and backgrounds it to resume looping. However, if you interrupt before the foreground job is done, the parent faithfully propagates the signal to the entry in the job table, and that kills the loop when it finally does restart. If you instead disown before the foreground job is done, the job table entry for the foreground job is deleted, so the parent never notices that it has exited and never resumes the loop at all. That latter bit is going to be nearly impossible to fix. Only the original parent shell can manage both the foreground job and the suspended subshell, which means it *can't* disown both of them if the loop is to remain blocked until the opportune moment. I think the only answer will be to refuse to disown. We already have a warning for jobs that can't be suspended, and one for disowning a job that is going to remain stopped. The former issue can probably be fixed by skipping those subshell job entries when propagating the TTY signal. We must be able to find those entries already to resume them when the current loop foreground job exits, so this shouldn't be impossible. I don't have time to look into this any further at this point. PWS?