Re: [PATCH] Fix foreground dead jobs in trap handlers reported like background ones in `jobs'

[Koichi Murase]

Thank you for your reply and sorry for the late reply.

2022年10月4日(火) 0:56 Chet Ramey <chet.ramey@case.edu>:
> > I expect the same behavior of `f1' and `f2' as far as there are no
> > background jobs.
>
> Why? f2 calls `jobs', and so requests information in a particular format,
> which may or may not be the same format as the default (compact) format
> bash uses when it reports job status before printing a prompt.

My point is *not* about the format of the output of `jobs', but
whether `jobs' should print the entries of foreground dead jobs, to
begin with.

I think this is related to why the job entries of the foreground jobs
are preserved in special contexts such as trap handler, bind -x,
PROMPT_COMMAND, etc. (see the discussion later).

> Here's how it works. ...

I understand all of these because I read the code to create the patches.

> When the shell is interactive, you get notified about
> dead jobs in two places: before the shell prints a new prompt, and after
> the shell waits for a foreground process to exit and discovers that a
> job has completed. You'd think the first would be enough,

No. I know that that is needed. To be honest, I actually thought that
in the opposite way as ``We would primarily check the jobs at the end
of a foreground process, but it would be suppressed in the special
contexts of trap/bind/PROMPT_COMMAND'.'

> but it leaves you
> vulnerable to job table explosion when you're running a bunch of jobs in a
> loop. The pragmatic solution of notifying when the job completes works well
> enough to avoid this. Bash has done this for decades.
>
> This default compact format prints a message that strsignal() returns,
> since it assumes you can easily associate it with the just-completed job.
>
> So you can see what happens. When run in the foreground, f1 prints the
> status from strsignal() after waiting for each process to finish. When
> run as a trap handler, f1 defers printing until it's about to print a
> prompt, then prints the status from strsignal(). When run in the
> foreground, f2 prints the status after waiting for each process to finish
> (which means that when you run `jobs' there are no un-notified processes).
> When run as a trap handler, f2 tries to defer printing the status until
> the trap handler completes, but the function forces status printing with
> `jobs' in a specific format, which means there are no un-notified jobs
> when the time comes to print the next prompt.

These also seem to just describe what is done in the current codebase,
which I think I understand.

> I think this is reasonable behavior.

I wouldn't say the current behavior is unreasonable or inconsistent,
which is the reason that I write the suggested behavior to be "more"
consistent at the end of my previous reply.

As I have written above, I think it is actually related to the reason
that the foreground jobs are preserved in the special contexts in
trap/bind -x/PROMPT_COMMAND/etc. I just thought that these entries are
just kept to defer printing the status, which would have occurred
immediately on the termination of foreground jobs if it were outside
the special contexts. In this sense, I thought the entries of the
foreground dead jobs are just an internal means to make the printing
defer, and not the real/practical job entries that are exposed to
users. In fact, now in the devel branch, we only preserve the
foreground dead jobs only when they need to be notified later (i.e.,
when they are killed by the signals). If it is just a means to defer
the printing to keep the job entries of foreground dead jobs, I think
it is "more" consistent that they should only affect the deferred
printing but not affect the builtin command `jobs' used by the users
to read and handle the job information. Or is there use cases of the
job entries of killed foreground dead jobs in the output of `jobs' for
the users?

Actually, this is related to the usage of the builtin command `jobs'
in my code. I would like to collect the information about the
currently-running and terminated background jobs using the `jobs'
builtin (by doing something like « jobs > tmp; read < tmp »). I
wouldn't like to pick up the foreground dead jobs by the `jobs'
builtin, but they are indistinguishable from the background dead jobs
and ``contaminate'' the result of `jobs'. This is the problem that we
were faced with in Ref. [1].

[1] https://github.com/akinomyoga/ble.sh/issues/78#issue-771281403

Although the foreground jobs that terminated without signals now do
not appear in the output of `jobs' now in the devel, the killed
foreground jobs still contaminate the output of `jobs'. As a
workaround, currently, my code discards all the information of jobs
that were terminated while evaluating PROMPT_COMMAND regardless of
whether they were foreground or background, but I still would like to
keep the information of the terminated background jobs if possible.

--
Koichi