yes `dir /p` needs to be fixed, and what you propose does work for the regular use (cmd in interactive mode...)
did some testing on windows which confirm that ENABLE_PROCESSED_INPUT should be kept in wait operation
* piping ctrl-c character in input stream doesn't stop the `dir /p` command * while hitting ctrl-c from keyboard (from the same pipe command) does * this means that the console is always kept in processed mode, and the ctrl-c is always returned through the ctrl-c handler and not as a character in input stream
actually, I'd prefer to have a dedicated helper to only wait for user input (it doesn't prevent to have another helper which does {print message(); wait for input(); print \r\n}); and we tend to place generic helpers in wcmdmain.c
there are some functional points to consider:
* may be setting console mode to ENABLE_PROCESSED_INPUT only is too aggressive; it looks like only clearing ENABLE_LINE_INPUT could be sufficient (you may want to keep ENABLE_ECHO_INPUT to have character printed) * console mode isn't reset on error path * the most annoying bit is that the ctrl-c isn't handled * this may end up a bit complicated as you need to wait on two objects; WCMD_choice could help for some waitable reads, but not all the input handles are opened in overlapped mode <g> * and also, it must ensure that the callers to that helper correctly support the STATUS_CONTROL_C_EXIT (`pause` seems to ignore it, `dir` now has support for ctrl-c return code)
note: builtin cmd doesn't properly implement pipes between commands, so don't try test it