Slightly improved wait-n-failure attached.
On Thu, Sep 5, 2024 at 12:10 PM Chet Ramey wrote:
>
> On 8/30/24 11:06 PM, Zachary Santer wrote:
> > CWRU/CWRU.chlog:
> > >8/26
> > >
> >
> > > execute_cmd.c
> > > [...]
> > > - execute_connection: in default mode, bash performs jobs notifications
> > > in an interactive shell between commands separated by ';' or '\n'.
> > > It shouldn't do this in posix mode, since posix now specifies when
> > > notifications can take place
> >
> > I forgot your comment below about the shell not being interactive any time
> > it's not accepting input from the user and took this to mean that 'jobs'
> > notifications would only ever be printed immediately prior to a prompt when
> > bash is in posix mode. I don't understand what posix mode changes relative
> > to the existing behavior if not that.
>
> In default mode, bash prints job notifications when executing a list (it
> calls lists `connections' internally). Commands in lists can be delimited
> by a `;' or newline; bash performs notifications between executing, say,
> the left and right sides of `command 1; command 2'. Now it doesn't do that
> in posix mode. It still does job notifications in other places that aren't
> strictly posix conformant.
>
> >
> > > jobs.c
> > > - notify_and_cleanup: make interactive shells notifying during sourced
> > > scripts dependent on the shell compatibility level and inactive in
> > > versions beyond bash-5.2
> > > Inspired by report from Zachary Santer
> >
> > Making 'jobs' notifications not happen while the interactive shell is
> > sourcing a script misses the cases where a function is otherwise executed
> > directly from the command line and of course a whole bunch of commands
> > separated by semicolons entered in one command line.
>
> What behavior do you want from the command lists that differs from what I
> described above? Since shell functions are essentially lists, you should
> get the same behavior from both.
You'd have to restrict job status notification to only ever occur
immediately prior to a prompt, in both posix and default mode, and
then you'd still need a blurb in the BUGS section of the manual saying
that 'set -b' has a potentially surprising impact on 'wait -n' in the
interactive shell.
For this to work, you'd have to choose one of the following new behaviors:
1) Background jobs that are both forked and cleared from the jobs
table by a call to 'wait' in the time between an accept-line and the
following prompt would never receive a job id or be notified to the
user in any way. No
[1] 16053
when it's forked, and no
[1]+ Done wait-n-failure::random_sleep
when it terminates. Only jobs that were forked and have not been
cleared from the jobs table when it's time to display the next prompt
would receive a job id or print the
[1] 16053
line. (That line isn't very useful anyway when you don't know what was
forked, i.e. because it wasn't simply the contents of the prior line
with an ampersand after them.)
2) Job ids assigned to background jobs continue to increase
monotonically, between accept-line and prompt, even as some of those
jobs are removed from the jobs table by calls to 'wait'. In this
scenario, the
[1] 16053
line can be printed when each background job is forked or immediately
prior to the
[1]+ Done wait-n-failure::random_sleep
lines. If instead, freed job ids can be assigned to new jobs again
before the following prompt, as is the case now, multiple jobs with
the same job id would show up as "Done" at the same time.
If the 'jobs' builtin is called in the midst of a command list being
run with either behavior, this would cause the same updates to the
jobs table and list of saved pids and statuses as would occur
immediately prior to a prompt. The user would have to know that
calling the 'jobs' builtin would have an impact on what processes
'wait -n' without id arguments will return the termination status of.
That would have to be documented in the man page.
Of the above options, I think 1) is my preference. In either case,
though, the change in shell behavior evident to the user would extend
beyond the behavior of 'wait -n'. By contrast, making 'wait -n'
without id arguments return the termination status of a background job
that has already been notified to the user and clear that job from the
list of saved pids and statuses wouldn't necessitate any change to
notification behavior, albeit it might cause problems for code
intended for use within the interactive shell.
On Thu, Sep 5, 2024 at 4:18 PM Chet Ramey wrote:
>
> On 8/30/24 11:06 PM, Zachary Santer wrote:
> > On Mon, Aug 26, 2024 at 10:57 AM Chet Ramey wrote:
> > However, I think the benefit to
> > consistent behavior far outweighs the hardship caused to whoever would
> > write a script intended for use within the interactive shell that depends
> > on 'wait -n' without id arguments ignoring background processes that the
>
