Cygwin doesn't handle SIGWINCH properly in Windows Terminal

[Brian Inglis]

On 2021-02-13 03:39, Alvin Seville via Cygwin 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
> 
> As you see Windows Terminal doesn't handle SIGWINCH
> <https://man7.org/linux/man-pages/man7/signal.7.html> properly. However
> everything works fine when I execute my script directly from Cygwin
> Terminal without Windows Terminal which users told
> <https://github.com/microsoft/terminal/issues/9113#issuecomment-777703560>
> me that it seems to be a Cygwin bug.

Don't really see that given that the signal and size info should come from the 
terminal.

Running bash trap -l shows Cygwin has SIGWINCH as 28.
Does this script work when run using > ...\bash script under the cmd shell?
What does Windows terminal do to report window size change, is that available to 
the Cygwin console code, and how does it handle that?
It is possible that the interface and/or signal number is different.

Perhaps repost with a readably reformatted or attached script, and start a 
terminal log on a run with bash -vx to see whether and what signal is received 
and whether the changed size is reported, and attach that.

-- 
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.]