bug-bash
[Top][All Lists]
Advanced

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

Re: 'wait -n' with and without id arguments


From: Chet Ramey
Subject: Re: 'wait -n' with and without id arguments
Date: Mon, 26 Aug 2024 11:01:27 -0400
User-agent: Mozilla Thunderbird

On 8/16/24 8:21 AM, Zachary Santer wrote:
On Wed, Aug 14, 2024 at 11:22 PM Zachary Santer <zsanter@gmail.com> wrote:

The implicit 'jobs' isn't happening before each PS1, but after each
command completes. Thus, all the
[1]   Done                    random_sleep
notifications when sourcing wait-n-failure, before it prints
3 processes waited / 8 processes forked
1 seconds
and exits.

So, actually only doing the implicit 'jobs' work and moving things
from the jobs table to the list of saved pids and statuses before each
PS1 *would* be a solution here. When sourcing wait-n-failure, it's
going to do all its work before any PS1 prompt. Same deal if a user
wants to call a function with 'wait -n' in it from the command line,
invoke the edit-and-execute-command readline command, or just type a
bunch of different commands separated by semicolons into a single
command line.

This breaks down with 'set -b'/'set -o notify'. Short of 'wait -n'
printing a warning message or erroring out when it is invoked while
'set -b' is active, this isn't a complete solution.

If you enable the notify option, which is not the default, you should be
responsible for managing the consequences. notify is always going to result
in different behavior; see

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_11


I really think the solution here is for 'wait -n' to return the
termination status of a child process that has already terminated and
that the user has already been informed of. Ultimately, whatever set
of commands is being invoked together and the user who is being
informed of terminated child processes are two different things.
Informing the user does nothing for the set of commands.

No, that counts as notification. After the user is notified, the shell
is free to remove the job from the list. Bash happens to keep the status
around for a while; kre, for instance, advocates removing it entirely.


--
``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/

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


reply via email to

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