From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=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 2ff79deb for ; Tue, 30 Jul 2019 00:01:25 +0000 (UTC) Received: (qmail 3167 invoked by alias); 30 Jul 2019 00:01:18 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24110 Received: (qmail 27346 invoked by uid 1010); 30 Jul 2019 00:01:18 -0000 X-Qmail-Scanner-Diagnostics: from mail-lf1-f42.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25524. spamassassin: 3.4.2. Clear:RC:0(209.85.167.42):SA:0(-1.9/5.0):. Processed in 2.367254 secs); 30 Jul 2019 00:01:18 -0000 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.167.42 as permitted sender) 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=ty5Dp0tsn/ItUraIuYaWqg+uOFrf6VqRWuukBip4EQc=; b=PzoqRpTSnqb39XjdC5jmn+mYHbJ1SBGgoDKlevtCFIExaeEmqZxpa8f17lF1B692/Y 7HKvPaXNtyBbMkKsYL/X4B7g6XaUZz1TccltCQbUp22NNHDmjGg4kIm6pYngEta+wEop 0lqKQplVX4mKJUJL6QUkHD2SxFjYifvxbQEpMdo1JardtN8BbGkRk0FEpMZ8Gjsd0XpZ AlofTzyqN3ua5MR5E5Lt7HvapWInoNpVBrQ4Ex+XdjxiPST9BQo1Y0OWrqSdsxYbqJL3 wCJL+5uA7NNBpRjDpDofpVup/vs3CdY82gzAKBEoufdQEK4IQ5EcuJW/mguW1XIPKHIO yEdA== 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=ty5Dp0tsn/ItUraIuYaWqg+uOFrf6VqRWuukBip4EQc=; b=PKOksfztCrJ1mViYC+FhB7yo4gEdjNqoQR3ZjRCAu2ZJUj9GQ0Tew9ygSvQ2s75SJi ajGAsiY9Q2JpCkRuJvl2mnWF+UXUF4NnS0FiAtK2m/GTCrfx7CNWlgWyfgv49MHdwVZU 2WXVuL3+bRh6V75jk8nvdtm2p/xu350DU7JXI0wkWPmQqJOzbUoCSS9AJZGY+8wqK6bN KkyqiWsrE5KgRMhTXN1NtYb5LdDlw7AAR3H++sWrApCFQdXqWnu0ZBSq6WgyivW+BHlJ XLCK52ixpI6uT5ZA45PVshTREWkhIxsrE6ArqdWJmlreupvzU2PgGmdt0TUMveRME9On GqJw== X-Gm-Message-State: APjAAAXRG5n1bT2k471gsNPF8OcpgR+LPBQI62WdhGQ2F9EsgZDc8Xkb ooEf6KcH85XPgunzKZ1dXgrAGrsnL7oHe0Y83kH1I40t X-Google-Smtp-Source: APXvYqxBLoKP2RS0r16Z6MgeS3neP3XgzfF8D1dV7s8e4QcxAkF1XSamVMOnq7Xs/6pUmnJ5ZsVQJ8B/YTVTFp5NUbs= X-Received: by 2002:a19:7401:: with SMTP id v1mr52456834lfe.155.1564444842186; Mon, 29 Jul 2019 17:00:42 -0700 (PDT) MIME-Version: 1.0 References: <20190628110430.GA13790@zira.vinc17.org> <20190729152309.GA17940@cventin.lip.ens-lyon.fr> <20190729204857.GA28524@zira.vinc17.org> In-Reply-To: <20190729204857.GA28524@zira.vinc17.org> From: Bart Schaefer Date: Mon, 29 Jul 2019 17:00:30 -0700 Message-ID: Subject: Re: kill the LHS command of a pipe once the RHS command terminates To: Zsh Users Content-Type: text/plain; charset="UTF-8" On Mon, Jul 29, 2019 at 1:50 PM Vincent Lefevre wrote: > > > > Concerning the documentation, the zshexpn(1) man page does not say > > > that a process in process substitution is run in background. > > > > They have to be, otherwise either you'd need unlimited buffering or > > the read of the descriptor could deadlock. > > I don't see how this is related to buffering. This would be the same > case as with a pipe (cmd1 | cmd2), for which both commands run in > foreground and there are no buffering issues. You're wrong about this. In (cmd1 | cmd2), zsh forks off cmd1 into its own process. It is effectively "in the background" even though the entire pipeline is considered to be in the foreground; the only process that is really "in the foreground" is cmd2. If cmd2 stops reading its stdin, cmd1 will eventually either block or get a SIGPIPE. If both processes were in the foreground, they could get into a state where neither can make any progress. The same is true with <(...). (Aside, in bash/ksh93 (cmd1 | cmd2) puts cmd2 in a forked process instead, and keeps cmd1 in control.) > It says that jobs explicitly put into the background are run > asynchronously, but nothing about the converse. I'm not sure how you get "nothing about the converse" from "Certain jobs are run asynchronously ... OTHER THAN THOSE explicitly put into the background;" ("other than" refers to "certain jobs" that are asynchronous but "(not) explicitly" backgrounded) and "Examples of such asynchronous jobs are process substitution" ... but in any case this was one of those cases where the zsh manual assumed you know how "most" shells work and therefore what these terms mean, and that it only had to explain what it might be doing differently. The whole manual page used to be written this way and we are only gradually turning it into a standalone reference.