Re: [PATCH v18 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.

[Joe Souza (＠JoeS209)]

On Thu Feb 27 10:01:08 2025 +0000, eric pouech wrote:
> 1) concerning the mode for waiting a key, 
> * ENABLE_PROCESS_INPUT is already set... default mode is 0x1f7 (so all
> flags except ENABLE_WINDOW_INPUT and ENABLE_VIRTUAL_TERMINAL_PROCESSING)
> * so IMO you just need to clear the ENABLE_LINE_INPUT flag to get key
> press without wating for end of line
> 2) for ctrl-c handling
> * likely the ctrl-c is reported through the ctrl-c handler and it's not
> clear to me if native does break the read operation in this case and
> whether we should wait on both read operation & ctrl-c event
> I'll answer #2 first:
> Under Windows, Ctrl-C definitely does break out of a DIR /P pause.  Regarding the second part, I completely agree that the proper way to handle this would be to wait on both input and the Ctrl-C event.  I have tried this.  You may recall in an earlier iteration of my changes for a prior merge request, I left some code commented out which I then removed after you raised issue with it.  This code was a call to WaitForMultipleObjects, waiting on both the input handle and the Ctrl-C event.  The problem here which I believe I had stated at the time is that with Wine, the input handle is always signaled, even if there is no input waiting.  The result was that the wait was always being satisfied immediately and DIR /P was not pausing at all.  So that approach was abandoned in favor of what we have now.

#1:
This code here is based on the previous code for WCMD_Pause.  That code was setting console mode flags to 0.  I'm guessing that PAUSE has operated this way for many years.  My changes use the new WCMD_wait_for_input for both PAUSE and DIR /P, and I did not want to break PAUSE behavior.  Further, ENABLE_ECHO_INPUT is on by default, and counter to Microsoft's docs for SetConsoleMode, on Wine the character is echoed even if ENABLE_LINE_INPUT is disabled.  The end result here is that DIR /P was echoing the character that the user pressed, whereas Windows does not exhibit that behavior.

All that said, based on shortcomings in Wine that I discuss above, I believe that my changes here are currently the best approach.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/7400#note_96130