On Mon 2019-04-15 17:35:49 -0400, Chet Ramey wrote:
> I'll probably release a patch, yes. In the meantime, distributions are free
> to take the change and apply it to their versions.
Thanks for the followup! I've updated https://bugs.debian.org/920455
with the appropriate details.
--dkg
On 4/15/19 2:40 PM, Daniel Kahn Gillmor wrote:
> On Sat 2019-04-13 14:03:22 -0400, Chet Ramey wrote:
>> It's an easy change. See the attachment.
>
> Thanks! The attached patch removed a comment and changed an #if 1 to
> #if 0, but i think the comment change is just a cleanup reflecting the
> prev
On Sat 2019-04-13 14:03:22 -0400, Chet Ramey wrote:
> It's an easy change. See the attachment.
Thanks! The attached patch removed a comment and changed an #if 1 to
#if 0, but i think the comment change is just a cleanup reflecting the
previous state of the codebase. Is that right?
> I agree tha
On 4/12/19 4:28 PM, Daniel Kahn Gillmor wrote:
> None of the other bourne-derived shells that i have tried have a builtin
> wait that waits on child processes that they didn't directly create.
> It's odd that bash 5.0 does this. I don't have any objection to the
> wait builtin waiting on coproces
On Fri 2019-04-12 12:05:24 -0400, Chet Ramey wrote:
> But the execs mean that the shell that is eventually invoked to run the
> `wait' is the parent of the process substitution. So the subshell has
> children, whether or not it has run the process substitution itself.
Yes, agreed. This is the sit
On 4/11/19 6:03 PM, Daniel Kahn Gillmor wrote:
> https://bugs.debian.org/920455
It wouldn't really affect that. The reason `wait' waits for process
substitution processes is that they set $!, making them "known to the
shell" and subject to wait without arguments.
Over in the "here strings and tmpfiles" thread, a distraction came up,
which i'm splitting out into a separate thread. Please don't conflate
the two, i'm just looking for further clarity about process
substitutions and the wait builtin.
dkg and chet wrote:
https://bugs.debian.org/920455
>>>
