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