Re: Cygwin doesn't handle SIGWINCH properly in Windows Terminal

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2021-02-16 04:31, Takashi Yano via Cygwin wrote:
> On Tue, 16 Feb 2021 19:31:54 +0900
> Takashi Yano wrote:
>> On Sun, 14 Feb 2021 17:43:58 +0900
>> Takashi Yano wrote:
>>> On Sat, 13 Feb 2021 20:39:39 +1000
>>> Alvin Seville wrote:
>>>> Windows build number: Win32NT 10.0.19042.0 Microsoft Windows NT 10.0.19042.0
>>>> Windows Terminal version (if applicable): 1.5.10271.0
>>>> Script to reproduce this issue:
>>>> #!/usr/bin/env bashfunction outputText()
>>>> {
>>>>    local text=$1
>>>>    local -i textLength=${#text}
>>>>
>>>>    local -i line="$(tput lines) / 2"
>>>>    local -i col="$(tput cols) / 2 - $textLength / 2"
>>>>
>>>>    clear
>>>>    echo -en "\e[$line;${col}H$text"
>>>> }
>>>> trap "outputText 'Hello world!'" SIGWINCH
>>>> outputText 'Hello world!'while truedo
>>>>      :done

>>> This is because cygwin console handles SIGWINCH when the input
>>> messages is processed. If the process does not call either read()
>>> or select(), SIGWINCH will not be sent. This is the long standing
>>> problem of the implementation and hard to fix.

>> I came up with a solution for this issue and implemented that.
>> It seems working as expected as far as I tested while I did not
>> have to change the code much contrary to my concern.
>>
>> The point of the idea is to keep the basic structure of the
>> console code unchanged and introduce a new thread which handle
>> the only signals derived from input records. Handling of Ctrl-S
>> and Ctrl-Q also added.
>>
>> I would like to submit the patch to cygwin-patches mailing list.
>>
>> Corinna, could you please have a look?

> v2: Problems when input echo is stopped by Ctrl-S is fixed.

Do these changes (still?) honour stty flags like isig, ixany, noflsh and handle 
interrupt character settings for e.g.:
	intr = ^C; quit = ^\; swtch = ^Z; start = ^Q; stop = ^S; susp = ^Z;
	discard = ^O;
?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]