2024年5月1日(水) 22:58 Chet Ramey <chet.ra...@case.edu>: > Yes, and I said I could work around this case.
Thank you for your consideration. > > [1] https://lists.gnu.org/archive/html/bug-bash/2022-10/threads.html#00054 > > [2] https://lists.gnu.org/archive/html/bug-bash/2022-11/threads.html#00049 > > (continued. I haven't received a reply) > > To what? To the email [2]. In particular, to the question in the second paragraph [2]. > > I'm not sure about the answer, but kre's opinion seems reasonable to > > me. > > OK. The standard does say "reporting the exit status with the special > parameter '?'" in > > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02 I think the description of the standard is still unclear, or the standard doesn't try to specify this detail. I'm not sure whether we can relate "the exit status reported by $?" and "the job status that has been reported'' just from the description of the standard. However, when we try to define "the job status that has been reported" consistently with both the standard description and the actual behaviors of shells, I think it is *one* reasonable interpretation to regard the job status is reported when the exit status is stored in $?. > Correct. Is setting $? sufficient, or does the standard mean the reporting > on foreground jobs that are killed by a signal -- one that shells don't > ignore -- before the next command, which is what all shells do? > > For instance, if you run > > sleep 20; jobs As far as I test it, yash and zsh don't print the information of the signaled foreground jobs in this case, though ash/ksh families and bash/posh print it as you tell. If we interpret $? can be used to ``report'' the foreground job status, the standard technically wouldn't require printing the job information to stdout in this case, but it doesn't prohibit printing either. > and hit the `sleep' with SIGUSR1 from another process, all shells will > print some message about the process exiting due to SIGUSR1 before `jobs' > is executed, and `jobs' prints nothing, because the reporting has already > happened. In that theory, what happens when `sleep 20' is successfully terminated without any signals? If the `reporting' must be the actual text printed to stdout, « sleep 20; jobs » should print the job information of the foreground terminated job `sleep 20', but not a single does that. ---- To summarize my current thinking, I feel the standard didn't intend to specify the detailed behavior for the foreground jobs. I don't expect the `jobs' builtin to print any foreground jobs for consistency with the behavior in the existing shells (except for Bash trap/bindx/PROMPT_COMMAND handlers and 5.3 funsubs). An ``interpretation'' of the POSIX standard consistent with the existing shell behavior would be to count $? as `reporting'. With this interpretation, the `jobs' builtin will never print foreground jobs because, at the point when the `jobs' builtin is running in the foreground, any other foreground jobs should have been terminated (while setting $?) or turned into background jobs as no more than one jobs can run in the foreground at the same time. In a case, the `jobs' builtin is inside a background job, the foreground jobs that started after forking the background jobs are not visible to the `jobs' builtin anyway. -- Koichi
