Re: bin/48138

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/48138; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Steffen Nurpmeso <steffen%sdaoden.eu@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: bin/48138
Date: Sun, 06 May 2018 07:50:11 +0700

     Date:        Sat, 05 May 2018 23:53:38 +0200
     From:        Steffen Nurpmeso <steffen%sdaoden.eu@localhost>
     Message-ID:  <20180505215338.NXsqn%steffen%sdaoden.eu@localhost>
 
   | I wondered because i did not really understand the signal number
   | i think -- SIGCHLD?
 
 SIGSTOP (145-128 == 17 == SIGSTOP)
 
   | SIGSTOP, are you sure, wasn't that SIGCHLD?
 
 No, when a process stops, the parent is told in the
 wait which signal caused it (the child) to stop - in this
 case the kill -STOP sends SIGSTOP (a ^Z would send
 SIGTSTP if the process had been in foreground,
 and status would be 146).
 
 The parent (the shell here) might be delivered a
 SIGCHLD (if it requested one) to inform it of the
 child's status change (so it knows to wait) but
 sh doesn't use that (and even if it did, the SIGCHLD
 comes to the shell, it would, or should, never be
 an exit or stop status from a child - it is not a signal
 that causes process termination, ever.)
 
   | ... But with some
   | trying i see that No. 1 (bash) acts the very same:
   |
   |   [1]+  Stopped                 sleep 45
   |   #?0[steffen@essex tmp]$ wait
   |   #?0[steffen@essex tmp]$ wait %1
   |   bash: warning: wait_for_job: job 1 is stopped
 
 Yes, I saw that, but
 
   | So desirable to follow, given that nothing better exists.
 
 ksh93 does not, it does wait more like POSIX suggests
 it should (but looks to e full of bugs).   zsh doesn't either,
 but appears to have a different set of bugs.
 
 I am really not sure what is best here, but I really think that
 a simple wait should wait for the process to finish.   zsh appears
 to restart the process if it is waited on and was stopped
 (but then waits uninterruptedly, which is not good.)
 
   | You have been there before.  I do not know, i would say "in
   | interactive context, yes".
 
 wait is not all that common interactively, it isn't needed (unlike
 in scripts) as the shell waits automatically when needed,  the
 jobs command (and just getting the next prompt) are more
 common ways to determine when a process has finished
 (or changed state.)
 
   | Oh, what do you think!  Well indeed the old Lion (10.7.5) says:
   |
   |   ?0[sdaoden@devon shared]$ /bin/ksh 'echo ${.sh.version}'
   |   Version M 1993-12-28 s+
 
 Looks to be a slightly(?) old ksh93 - did that not have KSH_VERSION?
 I was going to suggest ${.sh.version} but a lot of the derived from
 pdksh versions of ksh do not implement that.
 
   | whereas here i have
   |
   |   #?0[steffen@essex tmp]$ echo $KSH_VERSION
   |   @(#)MIRBSD KSH R56 2018/01/14
 
 mksh - an entirely different beast indeed.
 
 Is there anyone else bothering to read this PR, who has an
 opinion on what wait (the sh builtin command) should do
 when there are stopped children - both in the case where
 the command is a bare "wait" and in the case where the
 wait is given some kind of pid/job parameter, and that one
 selects a child that is stopped?
 
 kre