Steffen Daode Nurpmeso dixit: >though WCONTINUED has been implemented by millert@ on 2003-08-03 >(according to git(1) log). In fact, testing the patched mksh(1) >under OpenBSD 5.4 doesn't get the event right… Ouch!
OK, I’ve applied the patch⁰. Testing gives: ⓪ https://www.mirbsd.org/cvs.cgi/src/bin/mksh/jobs.c.diff?r1=1.100;r2=1.101 tg@blau:~ $ /bin/sleep 60 & [1] 1399 tg@blau:~ $ kill -STOP %1 [1] + Suspended (signal) /bin/sleep 60 tg@blau:~ $ jobs [1] + Suspended (signal) /bin/sleep 60 tg@blau:~ $ kill -CONT %1 tg@blau:~ $ jobs [1] + Suspended (signal) /bin/sleep 60 … right, it doesn’t catch it, but… waitpid() is only ever run in j_sigchld() in mksh! tg@blau:~ $ kill -CHLD $$ tg@blau:~ $ jobs [1] + Running /bin/sleep 60 So it “works”. Of course, this can probably be improved. Either it’s a kernel issue (maybe other kernels send SIGCHLD to parents when their children get CONTinued, but I doubt that) or we’ll need to figure out other ways to get the shell to notice. A brute force thing could be to patch the shell to run j_sigchld() every time the job control builtins and kill are run (this will still miss some, like async notify when /bin/kill is used instead). Maybe millert@ has some idea? By the way, I found 「find / >/dev/null &」 to be a much better testing command because ① its activity can be seen and heard, and ② the kernel has special handling for sleeping processes and I wanted to exclude this as error source. Thanks, //mirabilos -- 20:49⎜«Natureshadow» Oops, jetzt hab ich mir doch glatt beim Trinken ⎜ Mineralwasser ins Ohr gekippt… 21:04⎜«mirabilos» ist das siggbar? █ PS: سمَـَّوُوُحخ ̷̴خ ̷̴خ ̷̴خ امارتيخ ̷̴خ 21:05⎜«Natureshadow» mirabilos: was sollte dich davon abhalten…
