
Ask HN: Windows terminal (cmd.exe) signal handling for subprocess c++ - vladihost
Suppose we have small program, written in C++, which looks like below.  
This program itself <i></i>intentionally<i></i> does NOT perform signal handling via WinAPI call `SetConsoleCtrlHandler` - it&#x27;s important part of question.<p><pre><code>    #include &lt;stdio.h&gt;
    #include &lt;stdlib.h&gt;

    int main() {
      while(true) {
        int status = system(&quot;EXTERNAL COMMAND&quot;);
        printf(&quot;RESULT STATUS = %d\n&quot;, status);
      }
    }

</code></pre>
When `Ctrl+C` key combination have been pressed in terminal, program above have quite different behavior depend on which `&quot;EXTERNAL COMMAND&quot;` had been invoked<p>1) If external command is `pause`, program will stand in infinite loop, invoking `pause` command step by step, and will print `&quot;RESULT STATUS = 0&quot; many times`, while not terminated forced via process kill.  
2) If external command in `choice`, program will terminate immediately after `Ctrl+C` pressure. It will not print anything and does not return from `system` call.  
3) If external command is `set &#x2F;P VAR=`, program has much interesting behavior. When `Ctrl+C` pressed, program prints `&quot;RESULT STATUS = 1&quot; and continue working until first async call is performed.<p>First and second case can be explained in following manner. Terminal windows is proxt between user input and target program, so when user presses `Ctrl+C`, terminal window perform dispatch signal itself to target process.  
So some subprocesses can take manually terminal handler via `hConsole = GetStdHandle(STD_OUTPUT_HANDLE)` and perform own signal handling. Another subprocess does not do this, so signal passed into parent process and terminate it.<p>But third case causes big question. If child process intercepts `SIGINT`, why parent process perform terminating after first async call. If not, why it does not terminate immediately and why and how it prints `&quot;RESULT STATUS = 1&quot; and continue working.<p>Thanks
======
jenscow
I guess it depends on whether or not the child process has used
`SetConsoleCtrlHandler` and/or `SetConsoleMode`, which lets you determine if
^C should be processed as key input.

(don't forget, there is also Ctrl+Break - which also acts slightly
differently, depending on unknown conditions)

