On Mon, 18 Mar 2024 12:09:06 +0900 Takashi Yano wrote: > On Sun, 17 Mar 2024 14:10:55 +0100 > Dimitry Andric wrote: > > On 17 Mar 2024, at 13:50, Dimitry Andric <dimi...@unified-streaming.com> > > wrote: > > > > > > On 17 Mar 2024, at 13:35, Takashi Yano via Cygwin <cygwin@cygwin.com> > > > wrote: > > > ... > > >> > > >> I also test your test case: > > >> while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait > > >> -n || { echo 2: $?; exit 1; }'; do echo $((i++)); done > > >> in Linux (Debian 12.5), and the issue reproduced! > > > > > > Yeah, same here with bash 5.1.16(1)-release on Ubuntu 22.04. It errors > > > out with 127 after ~50-200 loops. > > > > Having built bash master (bash-5.2-27-gf3b6bd19) here, it consistently > > gives 127 in this area: > > > > https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/wait.def#n227 > > > > 211 #if defined (JOB_CONTROL) > > 212 if (nflag) > > 213 { > > 214 if (list) > > 215 { > > 216 opt = set_waitlist (list); > > 217 if (opt == 0) > > 218 WAIT_RETURN (127); > > 219 wflags |= JWAIT_WAITING; > > 220 } > > 221 > > 222 status = wait_for_any_job (wflags, &pstat); > > 223 if (vname && status >= 0) > > 224 builtin_bind_var_to_int (vname, pstat.pid, bindflags); > > 225 > > 226 if (status < 0) > > => 227 status = 127; > > 228 if (list) > > 229 unset_waitlist (); > > 230 WAIT_RETURN (status); > > 231 } > > 232 #endif > > > > So for some reason, wait_for_any_job() returns a negative value in this > > particular situation. > > Line 218 looks also suspicious.
Probably, this is not a bug. man bash says: If the -n option is supplied, wait waits for a single job from the list of ids or, if no ids are supplied, any job, to complete and returns its exit status. If none of the supplied arguments is a child of the shell, or if no arguments are supplied and the shell has no unwaitedâfor children, the exit status is 127. If the background process exited before calling 'wait -n', it returns 127. This is very different from wait() system call, which is necessary for any background joubs, otherwise zombie remains. In the shell, it is not necessary to call wait command for background jobs, therefore exit status of the background job which already exited is not held anymore. So, actual bug is in the test case. -- Takashi Yano <takashi.y...@nifty.ne.jp> -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple