On 6/9/19 8:58 AM, mwnx wrote:
> On Thu, Jun 06, 2019 at 03:18:16PM -0400, Chet Ramey wrote:
>>>If ID is not given, waits for all currently active child
>>>*processes*, and the return status is zero.
>>
>> OK, so the wording is the issue? What would work better? We could use
>> the "known t
On Thu, Jun 06, 2019 at 03:18:16PM -0400, Chet Ramey wrote:
> >If ID is not given, waits for all currently active child
> >*processes*, and the return status is zero.
>
> OK, so the wording is the issue? What would work better? We could use
> the "known to the shell" wording POSIX does, or
On 6/6/19 4:50 PM, Chet Ramey wrote:
> On 6/6/19 9:12 AM, Robert Elz wrote:
>
>> Whether bash works that way with processes created for process substitutions
>> (which are a non-standard thing to do) I don't know however.
>
> The shell doesn't really have to remember them at all -- ksh93 doesn't,
On 6/6/19 9:12 AM, Robert Elz wrote:
> Whether bash works that way with processes created for process substitutions
> (which are a non-standard thing to do) I don't know however.
The shell doesn't really have to remember them at all -- ksh93 doesn't, for
instance -- but bash remembers the last on
On 6/6/19 3:57 AM, mwnx wrote:
>> Not quite. `wait' without arguments waits for the last process
>> substitution, and the pid of that process is available in $! for the
>> cases you care about. If you are sure that your script hasn't started
>> any asynchronous processes since the last process sub
Date:Thu, 6 Jun 2019 09:57:24 +0200
From:mwnx
Message-ID: <20190606075724.GA9670@noisy>
| After all, it does wait for all other
| kinds of processes irrespective of when they were started or how
| many there are,
Shells aren't required to keep track of any proc
On Tue, Jun 04, 2019 at 07:19:02PM -0400, Chet Ramey wrote:
> On 6/4/19 4:34 PM, mwnx wrote:
>
> > Thanks for the explanation. In view of the change you describe,
> > there is another behaviour that I think might qualify as a bug. I'll
> > give you my actual use case first.
> >
> > I simply want to
On 6/4/19 4:34 PM, mwnx wrote:
> Thanks for the explanation. In view of the change you describe,
> there is another behaviour that I think might qualify as a bug. I'll
> give you my actual use case first.
>
> I simply want to make sure all processes running inside a given
> subshell are killed on
On Mon, Jun 03, 2019 at 03:42:22PM -0400, Chet Ramey wrote:
> Here's what happens. The relevant change is that wait without options now
> waits for the last process substitution, since that sets $! and is "known"
> to the shell.
>
> The sequence of events is approximately:
>
> 1. Subshell starts, f
On 6/2/19 7:55 AM, mwnx wrote:
> Bash Version: 5.0
> Patch Level: 3
> Release Status: release
>
> Description:
> Since bash 5.0, a subshell can get stuck (wait forever) in
> what looks like a pretty specific set of circumstances,
> namely when combining a group command or a func
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-Dl674z/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname o
11 matches
Mail list logo
