Comment 3 for bug 1064726
Revision history for this message
| Jilles Tjoelker (jilles) wrote Re: maybe cater to broken programs doing weird things with SIGINT | #3 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
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