From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-return-43514-ml=inbox.vuxu.org@zsh.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id ec01e308 for ; Fri, 21 Sep 2018 16:58:05 +0000 (UTC) Received: (qmail 6927 invoked by alias); 21 Sep 2018 16:57:51 -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: List-Unsubscribe: X-Seq: 43514 Received: (qmail 27891 invoked by uid 1010); 21 Sep 2018 16:57:51 -0000 X-Qmail-Scanner-Diagnostics: from know-smtprelay-omc-11.server.virginmedia.net 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(80.0.253.75):SA:0(-1.9/5.0):. Processed in 2.856037 secs); 21 Sep 2018 16:57:51 -0000 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Originating-IP: [92.27.217.10] X-Authenticated-User: p.w.stephenson@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=EPmyLGRC c=1 sm=1 tr=0 a=8ZNYBr2XW9PeDhz77hzA2g==:117 a=8ZNYBr2XW9PeDhz77hzA2g==:17 a=kj9zAlcOel0A:10 a=x7bEGLp0ZPQA:10 a=YR4_K0clAAAA:8 a=CQALL2ceOcKkcngrw14A:9 a=CjuIK1q_8ugA:10 a=waMAY2KAzxQUlx2gRwsv:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1537549062; bh=zoLvjBuRMMftxl5DhnT+lcn9gMKqmv7vq1EpZDYtdfQ=; h=Date:From:To:Subject:In-Reply-To:References; b=TYxXDbGkhXhw7OxJp2v7P4Xn9qXJvGh73e9DlDSUxXw1lS4afzj9ESfjFNwA5XeFI i8YQuQu+XUwAHqiPx5U6jJdX/JTAiBKwqdJ1FOmR13Dc6JCSio3fyxbxljJkgLAI7f ddAvG5vNGxMjFd4JseWNWdsSbA7kP3iigKzDWA6C424JFTUSJxn9+Oyeu29vXDUzPR 3FucAJdCKHdWT5XLakjuTeVgmNAFwyd0ozDc8bMVbnEBOG4IEfDrWFBqgeN8fwz/zo CreEz0ZZTXMTJYO7ZACfDSC/d5qWaR9dvw1dYtwhzzBNKbXM4aYMMLHjGmzZDufLyI CCENnLtzkkRNg== Date: Fri, 21 Sep 2018 17:57:40 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: long-standing tty related issue: wrapped Emacs not suspended Message-ID: <20180921175740.6ab97a81@pws-HP.localdomain> In-Reply-To: <20180920123005.GA20647@zira.vinc17.org> References: <20180920123005.GA20647@zira.vinc17.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfO8UWKwphoLSAM0N7up9WMkr3Yu7sw+/vrMkmFCUhqjIZjgBnsHthRui88O9WXo/EvkOOENhcLkfwjNLtZ+ZwUAmrQKkJRcMfN7dWJD9+o6PmbxLyshX Y50Pd6g0EUZogZzMp/NNY8mUo9jr3bQJhuM0rWsj4LY+js2EHF/+jhRWE05HqbNqFi5ejlD4t0D7sw== On Thu, 20 Sep 2018 14:30:05 +0200 Vincent Lefevre wrote: > is suspended as expected. But when Emacs is wrapped in a function, > it is not suspended. After "zsh -f": > > zira% e() { emacs -nw "$@"; } > zira% e & > > I cannot quit Emacs or get the zsh prompt. I need to kill the > terminal. I think this one *is* the same basic issue that Thilo was talking about. As you note, it's not new. (With the latest code I can only get this the way Thilo did, by suspending, putting it into the background, then into the foreground, then I can only get things to work again with kill -CONT from elsewhere and a bit of massaging to kill of the remaining goo. The code shown above actually works OK for me with a bg and fg.) Joey's explanation --- that there's another copy of the shell in play that's getting in the way of job control --- is the basic issue, and the "exec" workaround is what I would have recommended trying. However, there are a couple of interesting zsh-specific issues here. The fact that another instance of the shell is created on the ^Z is actually a special feature for allowing you to suspend builtins, designed for functions and pipelines with more processing in than this --- typically loops over external processes. The bog-standard shell thing to do is simply suspend the external process, and let the rest of the shell code take care of itself, which almost certainly isn't what you want if the function is doing something sophsiticated. Unfortunately zsh's enhancement is not doing you any favours in this case since you don't actually want any more shell code to run. The forked shell and the emacs go into different process groups, and when you pass them around between background and foreground they lose track of who's doing what where. It's not clear if this is a bug because this is entirely untrodden ground but it might be possible to get this to work with enough fiddling. My first simple-minded go didn't work (though was at least having effects on the right bits of the code, just not the effects I wanted). The other point is that in a lot of cases zsh will exec the final external programme anyway. However, it doesn't do it in the case of functions since it dosn't have enough knowledge of what needs to happen when the programme called by the function exits. With enough safeguards this could probably be got to work --- though this is definitely an optimisation rather than a bug fix and there is the danger of breaking things. Passing through the flag saying if this is the last chunk of code in the list being executed by the function and its parents is the most obvious necessary test, but I think most of the infrastructure for this already exists. For example, if you run { :; sleep 20; } & you should find there's no additional shell instance when the sleep is running (up to shell state that might get in the way --- I get an extra shell when running from the top-level shell in the window but not if I start a new one, for reasons that escape me completely). The other thing I can think of is we'd need to test for the presence of traps that might get called on function exit, including EXIT and DEBUG. This is interesting because they might not actually be present when the function starts, so we'd need a special version of the flag saying only exec if there are no relevant traps at the last command to be executed. I can't think of any other gotchas but there could well be some. It's not clear this is worth the bother. pws