Cygwin doesn't handle SIGWINCH properly in Windows Terminal

Takashi Yano takashi.yano@nifty.ne.jp
Tue Feb 16 11:31:34 GMT 2021


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.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>


More information about the Cygwin mailing list