From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 292 invoked by alias); 17 Apr 2018 05:39: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: List-Unsubscribe: X-Seq: 42665 Received: (qmail 28599 invoked by uid 1010); 17 Apr 2018 05:39:20 -0000 X-Qmail-Scanner-Diagnostics: from mail-pl0-f43.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.160.43):SA:0(-1.9/5.0):. Processed in 2.593613 secs); 17 Apr 2018 05:39: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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIMWL_WL_MED,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 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=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=vXKNpfzPrjKrZ+LhPZb1Jd7ZD0qj1rmSq+4pgI52Qa8=; b=VvPIv9KSieBZCh+J+1O4YUzg8JxasS8BySbU49vR2VUsOdvkwH3LGWoyszEle0QpX8 ZvHJ5LcwMe415snQr3YyyJUL4gKZSTt66Gdp8VP+8jmwlVKIUR/ENcFZUW0cJfvyGeBi MLZaa2Yzg0MCcyOPaW6tkpEddgc1ISx/JXNM2yrrClKzGcwRU74WJNb6Pt4GkqOn9kPL 2rwDnVgmxEYa96om5wKQds9+bUsPV9I4my7JOPsTrOxTiZWgPI9hbQYR2Ds+hTKlOeHD pofcclo2qwcGlQSJzw9PCc6VqA0heRodScZBvGwFtcc45rbR7mRtmWg0g4HtSgXf8PgK 8U5g== 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:mime-version; bh=vXKNpfzPrjKrZ+LhPZb1Jd7ZD0qj1rmSq+4pgI52Qa8=; b=DlW6DWs0zw1oQ/U4QqDeXH8wd5nmH0EH7R4KNx3LVOJv/VyZe4GOhzLCsUMHWueJQJ Hvkffyhbs9IxoHhGTIrEigZPMZpypHMJslH4j32nyHafIKiqVuTkYE+RR7BC8/ax88Ub Awn7PGa1KSPdoR5jIShmz8KRdqAFGbpgePxflUeg47AyzXhUrUVte2yfY2+WsXuh3wt8 oKkijOt9JQMVKV8PToY9oEFlY66OxF/lTQXoITbVqwA7qmtcv2J/V9Yv8QVqFZKgKUd/ LrBt9n8VDdeeRd7+YdPyhS1Bhss61ermSOSkxOPrzxGv1FCPMHnqO9S3SWWEg79dqwI/ xckQ== X-Gm-Message-State: ALQs6tAgUadMntmf8b/MJidtwlCdstJEawXnrzpntdT90hE3TWEhY3IW +IJC2aY4L3jwLhPZ7jtsY4DQFObY X-Google-Smtp-Source: AIpwx49FfmPwZ+He8fBwWjC8FPmljmR8Kno2cg0wuClFwtdfoZTvhq4E3GglCk2F8tQPvQR+ENSCQA== X-Received: by 2002:a17:902:6c07:: with SMTP id q7-v6mr769123plk.67.1523943554579; Mon, 16 Apr 2018 22:39:14 -0700 (PDT) From: Bart Schaefer Message-Id: <180416223910.ZM32002@torch.brasslantern.com> Date: Mon, 16 Apr 2018 22:39:10 -0700 In-Reply-To: <20180415185804.GB12549@chaz.gmail.com> Comments: In reply to Stephane Chazelas "Re: "echo | ps -j $(:) | cat | cat | cat" runs components in different process groups" (Apr 15, 7:58pm) References: <180323221959.ZM27569@torch.brasslantern.com> <20180324080514.txxyrb3qiztu4pqt@gmail.com> <180324150945.ZM32251@torch.brasslantern.com> <20180410124545.13fccd5d@camnpupstephen.cam.scsc.local> <20180410145926.64c4f671@camnpupstephen.cam.scsc.local> <180411151025.ZM19332@torch.brasslantern.com> <20180412172342.52df6b10@camnpupstephen.cam.scsc.local> <20180415162326.GA12549@chaz.gmail.com> <20180415185804.GB12549@chaz.gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: "echo | ps -j $(:) | cat | cat | cat" runs components in different process groups MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Apr 15, 7:58pm, Stephane Chazelas wrote: } } > > echo $(sleep 10) & echo started } > > } > > Only outputs "started" after 10 seconds. } > } > I would say that's actually correct. $(sleep 10) is *not* a } > background job, it's output has to be collected } } But it could do that collection in the child process like all } other shells do. Hmm. At first I was going to assert that this would require a lot of changes to order of operations in exec.c, but then I noticed this: % time echo $(sleep 5; echo finished) & echo started [1] 31864 started % finished [1] + done time echo $(sleep 5; echo finished) % The builtin "time" (keyword really) does not time other builtins, because they don't fork. So it's a silent no-op in this example, which might be an issue all its own. However, it still introduces an extra bit of wordcode. What it comes down to is that "time", being a keyword, is found at exec.c:3077 to have no "args" list, so prefork() is not invoked. Instead the rest of the expression is in the Estate. The whole thing gets backgrounded and then exectime() unpacks the state and re-calls execpline() When "time" is not there [or has been stepped over via exectime()], prefork() is immediately called and the substitution is waited for. So if, when we determine that "&" is the command separator, we could treat the command in the way the "time" prefix does, this would all work out without mangling execcmd_exec() and prefork(). However, there are some other unique zsh-isms that would be altered by this. For example: % echo ${foo::=bar} & echo $foo [1] 31940 bar % bar [1] + done echo ${foo::=bar} % unset foo % time echo ${foo::=bar} & echo $foo [1] 31943 % bar [1] + done time echo ${foo::=bar} % Note the assignment "sticks" in the current shell in the first case, because it happens before the fork, but is lost in the second case. Perhaps the former is a bug as well.