consider implementing WCE ipv WUE SIGINT handling

cf. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11886

Another one, from jilles:

mksh -c 'trap ":" INT; sleep 10; echo $?'

Interrupting (^C) that prints 0 with recent mksh, as long as sleep is the mksh builtin (even using /bin/sleep on MirBSD lets it print 0, whereas using /bin/sleep on FreeBSD or Debian, where it’s not the mksh builtin, prints 130).

This may or may not be related. My guess here is that the sleep builtin gets SIGINT but doesn’t kill itself which leads to the parent not seeing the signal. (Not getting it is also not nice, as that wouldn’t kill the sleep then.)

For the sleep problem:

22:47 < jilles> the wrong code for sleep is below this comment
22:47 < jilles> * strictly speaking only for SIGALRM, but the
22:47 < jilles> * execution may be interrupted by other signals
22:47 < jilles> it blindly returns 0 even if there was a signal

Where WCE was implemented in freebsd sh:

23:08 < jilles> the commit that initially implemented WCE in freebsd sh is r38521
23:10 < jilles> I changed it slightly in 2010 in r208881, to allow interrupting interactive cmd1; cmd2
23:10 < mirabilos> freebsd sh is ash based, so it would be completely different
23:11 < jilles> if job control is enabled, the shell will not receive a SIGINT from ^C while waiting for a job

so freebsd sh behaves as if SIGINT was sent to it if a foreground job control job in an interactive shell exited on SIGINT

Other:

22:37 < jilles> as I understand POSIX, the sleep builtin should handle signals as if they were sent to both the shell itself and the elided sleep child process
22:39 < jilles> the child process would have reset trapped signals to the default action

22:58 < jilles> btw relying on [EINTR] like c_sleep() does is racy
22:58 < mirabilos> why?
22:58 < jilles> because a signal handler might be called just before select(2) goes to sleep