bug-bash
[Top][All Lists]
Advanced

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

Re: 5.0 regression: Script stuck when waiting in trap


From: Chet Ramey
Subject: Re: 5.0 regression: Script stuck when waiting in trap
Date: Thu, 6 Jun 2019 15:18:16 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

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 substitution, you
>> can use $! directly. Otherwise, you can capture it into a variable
>> and use it in the `kill' command.
> 
> So, I tried the following:
> 
>      (echo a > >(cat; sleep 5); echo b > >(cat; sleep 1); wait)
> 
> which does confirm what you're saying; the command returns after
> only 1 second, not 5. However, `help wait` states the following
> (emphasis mine):
> 
>    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 "background jobs" or
even "running jobs" that some other shells use.


> Or, perhaps I'm misunderstanding the meaning of the term "active" in
> the above quote and for some reason the first process substitution
> is not to be considered "active"... Even so, I still don't really
> get the rationale behind only having `wait` wait for the last
> process substitution alone.

Because that's the one corresponding to $! (unless you've started
another background job since, which it doesn't check for but probably
should).

> 
> By the way, I did find a workaround for my use case; replacing the
> following in my trap:
> 
>     kill $(jobs -p)
> 
> with this:
> 
>     eval "kill \$(ps -o pid= --ppid $BASHPID)"
> 
> But I still think it would be nice if `wait` and `jobs` behaved more
> consistently. To sum up, here are the two points I find to be
> inconsistent:
> 
> 1. `wait` takes into account process substitutions (or at least the
>    last one) but `jobs` does not.

Because they're not jobs. They can't be the target of any of the
commands that operate on jobs, can't be moved between the foreground
and background, and don't have a job id. Plus the issues with the
controlling terminal.

> 
> 2. `wait` takes into account only the last process substitution but
>    takes into account all processes of other kinds, not just the
>    last of their kind (and this is not documented in the help or the
>    man page).

So you'd now like wait without arguments to wait on all process
substitutions? I don't think that's what most people want. It seems
like a reasonable compromise between waiting for none (pre-bash-5.0
behavior) and waiting for all. If you are interested in waiting for
all the process substitutions, you can collect the PIDs by getting
$! after each one starts, and wait for them explicitly.

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



reply via email to

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