Message335577
| Author | eryksun |
|---|---|
| Recipients | SamB, eryksun, foom, gregory.p.smith, jwilk, loewis, martin.panter, mwh, petri.lehtinen, pitrou, rnk, vstinner |
| Date | 2019-02-15.01:48:13 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1550195293.27.0.426543121794.issue1054041@roundup.psfhosted.org> |
| In-reply-to |
| Content | |
|---|---|
Gregory's last example reminded me that CMD checks for STATUS_CONTROL_C_EXIT for more than simply printing "^C". It also breaks out of a FOR loop when interactive and prompts to continue when executing a batch script. Normally CMD also gets a console control event when the user presses Ctrl+C, so it knows about the Ctrl+C regardless of the child's exit status. One exception is when we start a process with a new console via CMD's `start` command. In this case CMD doesn't get a Ctrl+C event, since it's attached to a different console. Another exception is a simulated keyboard interrupt (e.g. from C raise SIGINT or Python _thread.interrupt_main). In these cases, CMD depends on the exit status value to determine whether the process was terminated by the default Ctrl+C handler. I've demonstrated this in the files winsig.bat and winsig.py. Put both in the same directory and run winsig.bat. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2019-02-15 01:48:13 | eryksun | set | recipients: + eryksun, mwh, loewis, gregory.p.smith, foom, pitrou, vstinner, jwilk, rnk, petri.lehtinen, martin.panter, SamB |
| 2019-02-15 01:48:13 | eryksun | set | messageid: <1550195293.27.0.426543121794.issue1054041@roundup.psfhosted.org> |
| 2019-02-15 01:48:13 | eryksun | link | issue1054041 messages |
| 2019-02-15 01:48:13 | eryksun | create | |