Windows doesn't support sending signals to other processes as it is possible on POSIX platforms.
Using kill methods on Windows (like process.kill()
from Node.js) means the target process is getting killed forcefully and abruptly (similar to SIGKILL
).
However, in a console, processes can be terminated with the CTRL
+C
key combination.
Most programming languages have an implementation to capture this event (usually as SIGINT
), allowing applications to handle it and to terminate "gracefully".
The problem is that the CTRL
+C
key combination cannot be easily simulated for the following reasons:
- In order to be able to generate a CTRL+C event programmatically, several Console Functions need to be called - something which can usually only be done in lower-level programming languages.
- The process which should receive the CTRL+C event needs to live in its own console since the event is received by all processes attached to the same console. Spawning a process in a new console, again, is something which is usually only possible in lower-level programming languages.
This wrapper application does exactly the points described above.
The wrapper inherits stdout
, stderr
and the exit code from the child process and forwards stdin
to it. If there's an error with the wrapper itself, the exit code is -1
.
npm install ctrlc-wrapper --save-dev
import { spawnWithWrapper } from 'ctrlc-wrapper';
const child = spawnWithWrapper('node test/read-echo.js');
child.stdout.on('data', (data) => {
console.log(`stdout: ${data}`);
if (/READING/.test(data)) {
child.sendCtrlC();
}
});
child.stderr.on('data', (data) => {
console.log(`stderr: ${data}`);
});
child.on('close', (code, signal) => {
console.log(`close: ${code} ${signal}`);
});
To start the process node test/read-echo.js
with the wrapper:
go run ./cmd/start node test/read-echo.js
To terminate:
- Press
CTRL
+C
- Write
^C
tostdin
(captured by the wrapper) - Exit from within the child
pnpm build
It would be possible to generate the CTRL+C event directly from within start.exe
but this means an additional process must be spawned (e.g. cmd /c pause
) to prevent losing the original (parent) console during the console switch (FreeConsole
-> AttachConsole
). Using a separate binary to generate the CTRL+C event is the safer approach.
Both methods seem to protect from receiving the CTRL+C event in the current console.
However, spawning the child with CREATE_NEW_PROCESS_GROUP
would mean that we need to start another "wrapper" in which the "normal processing of CTRL+C input" is enabled first (via SetConsoleCtrlHandler
) before starting the actual child process.
Instead of ctrlc.exe
we might be able to terminate the target process by inject a thread into it, but this seems to be overly complicated...