On Thu Feb 13 11:09:41 2025 +0000, eric pouech wrote:
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 [1] https://www.dostips.com/forum/viewtopic.php?t=5859
I don't understand much of this. The variable added to propagate the event is a local variable in a single function only, as an optimization to prevent calling WCMD_is_command_aborted() multiple times.