[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coproc state wrongly inherited by subshell

From: Chet Ramey
Subject: Re: coproc state wrongly inherited by subshell
Date: Sun, 3 Dec 2017 15:14:24 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/29/17 5:36 PM, Tobias Hoffmann wrote:

> Description:
> As stated in the man page, bash will only allow a single coproc at a time.
> Thus, when a first coproc has already ended, a second one can be created.
> This can e.g. be verified by commenting out the upper #sleep line, below.
> Alternatively, you can remove the parens that start the subshell.
> But if we start a subshell while the coproc still runs, then wait inside
> the subshell
> until the first coproc has ended and then try to start another coproc, bash
> prints the
> infamous warning:
> ./test_sp1.sh: line 10: warning: execute_coproc: coproc [11030:COPROC]
> still exists
> The process id 11030 does (verifyably - e.g. add `ps a`) not exist the time
> the warning is printed.░

The question is how much to reset, and when to do it. A child process can
legitimately expect to inherit the coproc file descriptors from its parent
and read and write them under circumstances that have been valid
historically. The pid will never be valid for waiting in the child, because
it's not a child of the current shell, but simply testing whether or not
the process is alive isn't sufficient.

I think the best thing to do is to invalidate the pid whenever a child
process invalidates the coproc FDs.


``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]