From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-return-43567-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.0 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,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 5d2cb011 for ; Wed, 26 Sep 2018 17:42:36 +0000 (UTC) Received: (qmail 8975 invoked by alias); 26 Sep 2018 17:42:22 -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: 43567 Received: (qmail 15250 invoked by uid 1010); 26 Sep 2018 17:42:22 -0000 X-Qmail-Scanner-Diagnostics: from mail-lf1-f47.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.167.47):SA:0(-1.9/5.0):. Processed in 2.834855 secs); 26 Sep 2018 17:42:22 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=duzQ592DsPmv3JvLZONgTOJ1W7n3uGaGWdKxatqGr9U=; b=wJY50SoCDS3riPdr88FQzBe6nGLk44aQUt7F/PNeDbJ2c43SduwaaDXO1Uv1fr84JJ S4+ucc7KNdxHTAvc2jYKBqBIsi+o8y97RTrbZ0tBfstuMRjBMp2WQctOY7sr9uFrJv57 KWnvSDCOu99TdWTrZSRXKfS+5yBfq9wadn+4HhrFNBoacmYNu10zVYA972wFQ1Vn3ZQH omNGEtaL1JyCP+7Mzv7/wtVpocN4BtNJ9IOrzY0YpyP240MWWxz1bmHWHT8cx8Uad5qE JFUoqh5TU9ZLmfgB716ZkxD38kg+db8GC/iiLEHw7k+FlSuHcEI8vXwD/9EfFDugvzwd DCFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=duzQ592DsPmv3JvLZONgTOJ1W7n3uGaGWdKxatqGr9U=; b=E/UdULXTQfPJicgNNlabppNFRVc649N2fKMW4w3rd5Ytm8KMlO8UoyAPzDZ51yX9FC frb/swNovPROyCshuqMRK1G8HzDWxMOzHxuhyu+WpaokZILeli7g9daWnGyk9z9Y7xF6 QrXsyIORDvQpfQ6zAg4WrPvMTAV1nMVKOOOSGF20fFLiDEUeQTnpLNFNMRaOi/zZd1AG geTjcssCgcqga097OUKfDYHx7tvPaIylKWZQCFc79i/4tEYuW8oN1879kMvXo/AIxeuU 5kPhjmDNLbWkYvoUeMxzTTmIx7Zo7tTUlJURWKpAaDmBmsAZVeufqBQhRysJo8qQKLOQ pw2g== X-Gm-Message-State: ABuFfoh1bw4MfENSIwSDu3UEMJSKZQq12Usi0XwNEmJ70NclJVGFkCiT Afk92KZChwvNQ4J+v1JxIXtH01Y5da/BY5K+qdjTYrX8XwI= X-Google-Smtp-Source: ACcGV61jh+Icve/4A7QsSb7wj4/Y3EREssgG+9V7oQKdDWYCRDnyq+g9hxv602US/dbrNVNdz62QGllceSWXm+JCP08= X-Received: by 2002:a19:a2c1:: with SMTP id l184-v6mr4743627lfe.33.1537983732805; Wed, 26 Sep 2018 10:42:12 -0700 (PDT) MIME-Version: 1.0 References: <1537975883.2212216.1521491576.1CF7021B@webmail.messagingengine.com> <20180926155055eucas1p2a9eeba9267adcb603fbd609e47780010~X-fvU7i_h1255912559eucas1p2q@eucas1p2.samsung.com> In-Reply-To: <20180926155055eucas1p2a9eeba9267adcb603fbd609e47780010~X-fvU7i_h1255912559eucas1p2q@eucas1p2.samsung.com> From: Bart Schaefer Date: Wed, 26 Sep 2018 10:42:00 -0700 Message-ID: Subject: Re: What's a superjob? To: "zsh-workers@zsh.org" Content-Type: text/plain; charset="UTF-8" On Wed, Sep 26, 2018 at 8:51 AM Peter Stephenson wrote: > > Now we have just one process running: the main shell, and vi. Suppose > you hit ^Z. Then vi suspends. The main shell is in the middle of > running e, but it's not supposed to finish doing that till vi exits. > But without special action we're now back at the top-level shell prompt > and it never will execute. To add a bit more color here ... in the absence of this special handling, when vi is suspended, the shell has two choices: 1) treat vi as successfully completed and continue executing the function, or 2) treat vi as failed and stop the function at this point. IIRC different shells have historically made different decisions about this. I believe zsh's original behavior was #1, but that led to problems if (in this type of example) the remainder of the function depends on the content of the edited file. So #2 avoids side-effects, but causes at minimum annoyance because now you have a suspended vi but the rest of the function is simply gone. The other possibility is to immediately fork the whole function as soon as any non-builtin command is encountered, and then have the forked function fork again for the external job, to keep the process tree "normal". This would simplify the job handling in the main shell, but ruin the intention of the function being able to affect the main shell context in the case where no job control ever occurs.