Hi,
a couple of remarks (this isn't a full review yet)
the ctrl-handler + event look fine to me (I don't think native does process the ctrl-c by reading the input stream as 0x03)
but as the event is a one-time operation, it should be up to the caller to handle and propagate the ctrl-c information
I don't like the variable added to the DIR helpers to propagate it as I think this should be integrated as another value in the return code management instead
a couple of elements to reach that conclusion:
* a small test using `(dir /s *.* &&echo SUCCESS !errorlevel!||echo FAILURE !errorlevel!)` and breaking it with ctrl-c before it ends shows a `FAILURE 1` indicating that the event is propagated (at some point) through the return code which in turn sets the `ERRORLEVEL` * there are traces on Internet that the ctrl-c event is (at some point) propagated as what looks like an internal return code [1]; `-1073741510 = 0xC000013A = STATUS_CONTROL_C_EXIT` * and lastly, it could be (didn't test it though) that if an error occurs while using `WCMD_output `(eg disk full) that error should be propagated as well * this would also fit well into the various handling of ctrl-c while calling into other bat/cmd files (interruping the subcommand when in a CALL)
so this rather calls for:
* `RETURN_CODE WCMD_ctrlc_status(void)` : return `NO_ERROR` if event isn't set, `STATUS_CONTROL_C_EXIT` if set * then rework the DIR loops as being controlled by a `RETURN_CODE` (and keep looping while it's `NO_ERROR`)
-Eric