Cygwin doesn't handle SIGWINCH properly in Windows Terminal

Cygwin doesn't handle SIGWINCH properly in Windows Terminal

[Alvin Seville]

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.
-- 
alvinseville7cf@Alvins-MacBook-Pro ~ $* echo *"Best regards, Alvin Seville."*
&& exit*

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

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

[Takashi Yano]

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.

Therefore, I expect the following code should work, however I
have noticed it does not.

#!/usr/bin/env bash
function 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 true
do
  read # <- Call read here
done

This seems to be a bug of console code. I will submit a patch
for this issue.

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

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

[L A Walsh]

On 2021/02/14 00:43, Takashi Yano via Cygwin wrote:
> 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.
>
> ....
>
> This seems to be a bug of console code. I will submit a patch
> for this issue.
>   
---
I'd be careful 'fixing' this, as it seems to work the same
way on linux / bash.

I have this func setup on bash_profile & bashrc on
both cygwin and linux:

# display new size of terminal when resized
:                                                         
showsize () {\
  declare s=$(stty size); s="(${s// /x})"  ;\
  printf "%s" "$s${s//?/$'\b'}"       ;\
}; export -f showsize

trap showsize SIGWINCH
-----
Of note, on linux, I didn't have to reset LINES/COLUMNS,
however, on cygwin, I note that I should.

Oh well -- hmmm....is that a bug?

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

[Takashi Yano]

On Sun, 14 Feb 2021 12:44:32 -0800
L A Walsh wrote:
> On 2021/02/14 00:43, Takashi Yano via Cygwin wrote:
> > 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.
> >
> > ....
> >
> > This seems to be a bug of console code. I will submit a patch
> > for this issue.
> >   
> ---
> I'd be careful 'fixing' this, as it seems to work the same
> way on linux / bash.
> 
> I have this func setup on bash_profile & bashrc on
> both cygwin and linux:
> 
> # display new size of terminal when resized
> :                                                         
> showsize () {\
>   declare s=$(stty size); s="(${s// /x})"  ;\
>   printf "%s" "$s${s//?/$'\b'}"       ;\
> }; export -f showsize
> 
> trap showsize SIGWINCH
> -----

This has been working as expected without 'fix' because bash
calls select() rather than read() when it waits for user input.
The problem is in console read() and select() has been working.

Moreover, the problem is only in console read() while pty does
not have.

> Of note, on linux, I didn't have to reset LINES/COLUMNS,
> however, on cygwin, I note that I should.
> 
> Oh well -- hmmm....is that a bug?

What do you mean by "reset LINES/COLUMNS"? I am not sure what
is the behaviour diffrence in Linux and cygwin you mentioned.

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

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

[L A Walsh]

On 2021/02/14 16:05, Takashi Yano wrote:
> On Sun, 14 Feb 2021 12:44:32 -0800
> L A Walsh wrote:                                                        
>> showsize () {\
>>   declare s=$(stty size); s="(${s// /x})"  ;\
>>   printf "%s" "$s${s//?/$'\b'}"       ;\
>> }; export -f showsize
>>
>> trap showsize SIGWINCH
>> -----
> 

> 
> What do you mean by "reset LINES/COLUMNS"? I am not sure what
> is the behaviour diffrence in Linux and cygwin you mentioned.
---
	Actually not sure I can reproduce this now.  The only
thing I am noticing is that if bash is attached to /dev/pts3
(as in mintty), it works, but if attached to /dev/cons0 (as in
cmd.exe), nothing works as no signal is propagated from
the window resize to running program.

	AFAIK, though, that's always been one of multiple 
probs in using windows cmd with a bash shell.

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

[Marco Atzeri]

On 16.02.2021 03:17, L A Walsh wrote:
> 
> 
> On 2021/02/14 16:05, Takashi Yano wrote:
>> On Sun, 14 Feb 2021 12:44:32 -0800
>> L A Walsh wrote:
>>> showsize () {\
>>>   declare s=$(stty size); s="(${s// /x})"  ;\
>>>   printf "%s" "$s${s//?/$'\b'}"       ;\
>>> }; export -f showsize
>>>
>>> trap showsize SIGWINCH
>>> -----
>>
> 
>>
>> What do you mean by "reset LINES/COLUMNS"? I am not sure what
>> is the behaviour diffrence in Linux and cygwin you mentioned.
> ---
>      Actually not sure I can reproduce this now.  The only
> thing I am noticing is that if bash is attached to /dev/pts3
> (as in mintty), it works, but if attached to /dev/cons0 (as in
> cmd.exe), nothing works as no signal is propagated from
> the window resize to running program.
> 
>      AFAIK, though, that's always been one of multiple probs in using 
> windows cmd with a bash shell.
> 

maybe this is waht you are looking for:

# This causes bash to check the terminal size after every command
# and adjusts $LINES and $COLUMNS to the correct values.
shopt -s checkwinsize

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

[Brian Inglis]

On 2021-02-15 22:48, Marco Atzeri via Cygwin wrote:
> On 16.02.2021 03:17, L A Walsh wrote:
>> On 2021/02/14 16:05, Takashi Yano wrote:
>>> On Sun, 14 Feb 2021 12:44:32 -0800
>>> L A Walsh wrote:
>>>> showsize () {\
>>>>   declare s=$(stty size); s="(${s// /x})"  ;\
>>>>   printf "%s" "$s${s//?/$'\b'}"       ;\
>>>> }; export -f showsize
>>>>
>>>> trap showsize SIGWINCH

>>> What do you mean by "reset LINES/COLUMNS"? I am not sure what
>>> is the behaviour diffrence in Linux and cygwin you mentioned.

>>      Actually not sure I can reproduce this now.  The only
>> thing I am noticing is that if bash is attached to /dev/pts3
>> (as in mintty), it works, but if attached to /dev/cons0 (as in
>> cmd.exe), nothing works as no signal is propagated from
>> the window resize to running program.
>>
>>      AFAIK, though, that's always been one of multiple probs in using windows 
>> cmd with a bash shell.

> maybe this is waht you are looking for:
> 
> # This causes bash to check the terminal size after every command
> # and adjusts $LINES and $COLUMNS to the correct values.
> shopt -s checkwinsize

Newer bash man pages say this is the default; set in my .bashrc so I can't tell; 
bash man pages also say COLUNS and LINES are set on SIGWINCH if interactive:

$ man bash | egrep -A1 'COLUMNS|LINES|checkwinsize'
COLUMNS	
	Used by the select compound command to determine the terminal width when
	printing selection lists. Automatically set if the checkwinsize option
	is enabled or in an interactive shell upon receipt of a SIGWINCH.
--
LINES	Used by the select compound command to determine the column length for
	printing selection lists. Automatically set if the checkwinsize option
	is enabled or in an interactive shell upon receipt of a SIGWINCH.
--
checkwinsize
	If set, bash checks the window size after each command and, if
	necessary, updates the values of LINES and COLUMNS.

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

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

[Thomas Wolff]

Am 16.02.2021 um 07:20 schrieb Brian Inglis:
> On 2021-02-15 22:48, Marco Atzeri via Cygwin wrote:
>> On 16.02.2021 03:17, L A Walsh wrote:
>>> On 2021/02/14 16:05, Takashi Yano wrote:
>>>> On Sun, 14 Feb 2021 12:44:32 -0800
>>>> L A Walsh wrote:
>>>>> showsize () {\
>>>>>   declare s=$(stty size); s="(${s// /x})"  ;\
>>>>>   printf "%s" "$s${s//?/$'\b'}"       ;\
>>>>> }; export -f showsize
>>>>>
>>>>> trap showsize SIGWINCH
I have a similar trap in my .bashrc and it's being triggered when 
running bash from either cmd (conhost) or Windows Terminal and resizing 
them. Did I miss something in this issue?

>
>>>> What do you mean by "reset LINES/COLUMNS"? I am not sure what
>>>> is the behaviour diffrence in Linux and cygwin you mentioned.
>
>>>      Actually not sure I can reproduce this now.  The only
>>> thing I am noticing is that if bash is attached to /dev/pts3
>>> (as in mintty), it works, but if attached to /dev/cons0 (as in
>>> cmd.exe), nothing works as no signal is propagated from
>>> the window resize to running program.
>>>
>>>      AFAIK, though, that's always been one of multiple probs in 
>>> using windows cmd with a bash shell.
>
>> maybe this is waht you are looking for:
>>
>> # This causes bash to check the terminal size after every command
>> # and adjusts $LINES and $COLUMNS to the correct values.
>> shopt -s checkwinsize
>
> Newer bash man pages say this is the default; set in my .bashrc so I 
> can't tell; bash man pages also say COLUNS and LINES are set on 
> SIGWINCH if interactive:
>
> $ man bash | egrep -A1 'COLUMNS|LINES|checkwinsize'
> COLUMNS
>     Used by the select compound command to determine the terminal 
> width when
>     printing selection lists. Automatically set if the checkwinsize 
> option
>     is enabled or in an interactive shell upon receipt of a SIGWINCH.
> -- 
> LINES    Used by the select compound command to determine the column 
> length for
>     printing selection lists. Automatically set if the checkwinsize 
> option
>     is enabled or in an interactive shell upon receipt of a SIGWINCH.
> -- 
> checkwinsize
>     If set, bash checks the window size after each command and, if
>     necessary, updates the values of LINES and COLUMNS.
>

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

[Thomas Wolff]

Am 16.02.2021 um 11:26 schrieb Thomas Wolff:
>
> Am 16.02.2021 um 07:20 schrieb Brian Inglis:
>> On 2021-02-15 22:48, Marco Atzeri via Cygwin wrote:
>>> On 16.02.2021 03:17, L A Walsh wrote:
>>>> On 2021/02/14 16:05, Takashi Yano wrote:
>>>>> On Sun, 14 Feb 2021 12:44:32 -0800
>>>>> L A Walsh wrote:
>>>>>> showsize () {\
>>>>>>   declare s=$(stty size); s="(${s// /x})"  ;\
>>>>>>   printf "%s" "$s${s//?/$'\b'}"       ;\
>>>>>> }; export -f showsize
>>>>>>
>>>>>> trap showsize SIGWINCH
> I have a similar trap in my .bashrc and it's being triggered when 
> running bash from either cmd (conhost) or Windows Terminal and 
> resizing them. Did I miss something in this issue?
Yes I did. Sorry for the fuss.
>
>>
>>>>> What do you mean by "reset LINES/COLUMNS"? I am not sure what
>>>>> is the behaviour diffrence in Linux and cygwin you mentioned.
>>
>>>>      Actually not sure I can reproduce this now.  The only
>>>> thing I am noticing is that if bash is attached to /dev/pts3
>>>> (as in mintty), it works, but if attached to /dev/cons0 (as in
>>>> cmd.exe), nothing works as no signal is propagated from
>>>> the window resize to running program.
>>>>
>>>>      AFAIK, though, that's always been one of multiple probs in 
>>>> using windows cmd with a bash shell.
>>
>>> maybe this is waht you are looking for:
>>>
>>> # This causes bash to check the terminal size after every command
>>> # and adjusts $LINES and $COLUMNS to the correct values.
>>> shopt -s checkwinsize
>>
>> Newer bash man pages say this is the default; set in my .bashrc so I 
>> can't tell; bash man pages also say COLUNS and LINES are set on 
>> SIGWINCH if interactive:
>>
>> $ man bash | egrep -A1 'COLUMNS|LINES|checkwinsize'
>> COLUMNS
>>     Used by the select compound command to determine the terminal 
>> width when
>>     printing selection lists. Automatically set if the checkwinsize 
>> option
>>     is enabled or in an interactive shell upon receipt of a SIGWINCH.
>> -- 
>> LINES    Used by the select compound command to determine the column 
>> length for
>>     printing selection lists. Automatically set if the checkwinsize 
>> option
>>     is enabled or in an interactive shell upon receipt of a SIGWINCH.
>> -- 
>> checkwinsize
>>     If set, bash checks the window size after each command and, if
>>     necessary, updates the values of LINES and COLUMNS.
>>
>
> -- 
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

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

[L A Walsh]

On 2021/02/16 02:26, Thomas Wolff wrote:
>
> I have a similar trap in my .bashrc and it's being triggered when 
> running bash from either cmd (conhost) or Windows Terminal and resizing 
> them. Did I miss something in this issue?
>
>   
>>>>> What do you mean by "reset LINES/COLUMNS"? I am not sure what
>>>>> is the behaviour diffrence in Linux and cygwin you mentioned.
>>>>>           
----
running "-bash.exe" from Win-R:
>  whence -- -bash
-bash is /bin/-bash
-bash is /usr/bin/-bash
# initial size:
>  echo $LINES/$COLUMNS
30/80
>  showsize;printf "\n"
(30x80)
# shrink by 4 lines; showsize shows 26 lines, but ENV vars are unchanged
>  showsize;printf "\n$LINES/$COLUMNS\n"
(26x80)
30/80
>  stty size #shows:
26 80
#checkwinsize is set.
>  shopt -p checkwinsize
shopt -s checkwinsize
# same thing happens if I run 'cmd.exe' then start bash.exe

Normally, showsize displays size dynamically if I take my finger
off the mouse -- only way to see win size as I resize it.  However
in cmd.exe, it doesn't work.

AFAIK, its always been this way in Win7.  There were a bunch of bugs
in Win7 that MS refused to release, or in some cases, only upon request
(hotfix).  While there was a SP2 for the corresponding server edition
of Win7 (Win2008), they didn't want to ship a Win7SP2, because they
wanted to force people to upgrade to get fixes, so they left known bugs
in Win7 for as much as 6-7 years before they started telling users
who had known bugs they weren't going to fix, to upgrade to Win10 if
they wanted it fixed.

OTOH, if you want to fix this, that's great, but there are other
problems in cmd.exe like 'erase' not working in some ms-cmd line
programs (netsh coming to mind), but other ms-programs only work
when attached to 'cons0', like 'sc' doesn't read input
when it asks if you want to see more help when run from mintty,
but it works from cmd.exe.

Many of these were reported to MS before SP1, and weren't fixed.
Should be criminal -- if they won't support it, then source should
be released.
-l

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

[Takashi Yano]

On Sun, 14 Feb 2021 12:44:32 -0800
L A Walsh wrote:
> On 2021/02/14 00:43, Takashi Yano via Cygwin wrote:
> > 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.
> >
> > ....
> >
> > This seems to be a bug of console code. I will submit a patch
> > for this issue.
> >   
> ---
> I'd be careful 'fixing' this, as it seems to work the same
> way on linux / bash.
> 
> I have this func setup on bash_profile & bashrc on
> both cygwin and linux:
> 
> # display new size of terminal when resized
> :                                                         
> showsize () {\
>   declare s=$(stty size); s="(${s// /x})"  ;\
>   printf "%s" "$s${s//?/$'\b'}"       ;\
> }; export -f showsize
> 
> trap showsize SIGWINCH
> -----

This has been working as expected without 'fix' because bash
calls select() rather than read() when it waits for user input.
The problem is in console read() and select() has been working.

Moreover, the problem is only in console read() while pty does
not have.

> Of note, on linux, I didn't have to reset LINES/COLUMNS,
> however, on cygwin, I note that I should.
> 
> Oh well -- hmmm....is that a bug?

What do you mean by "reset LINES/COLUMNS"? I am not sure what
is the behaviour diffrence in Linux and cygwin you mentioned.

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

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

[Takashi Yano]

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?

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

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

[Takashi Yano]

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>

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

[Brian Inglis]

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

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

[Takashi Yano]

On Tue, 16 Feb 2021 09:26:52 -0700
Brian Inglis wrote:
> 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;
> ?

Basically yes. However, stty noflsh, flusho and Ctrl-O
does not take effect in the current code with/without
the patch.

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

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

[Thomas Wolff]

Am 16.02.2021 um 21:37 schrieb Takashi Yano via Cygwin:
> On Tue, 16 Feb 2021 09:26:52 -0700
> Brian Inglis wrote:
>> 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;
>> ?
> Basically yes. However, stty noflsh, flusho and Ctrl-O
> does not take effect in the current code with/without
> the patch.
Output flushing doesn't work in the pty either, and neither in Linux. 
The setting seems to be a relic from Unix systems.

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

[Brian Inglis]

On 2021-02-16 13:50, Thomas Wolff wrote:
> Am 16.02.2021 um 21:37 schrieb Takashi Yano via Cygwin:
>> On Tue, 16 Feb 2021 09:26:52 -0700
>> Brian Inglis wrote:
>>> 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;
>>> ?
>> Basically yes. However, stty noflsh, flusho and Ctrl-O
>> does not take effect in the current code with/without
>> the patch.
> Output flushing doesn't work in the pty either, and neither in Linux. The 
> setting seems to be a relic from Unix systems.

It was an interactive shortcut to send excessive output to the bit bucket 
*after* a command was run, which saved dialup I/O charges, and time, when dialup 
was slow and expensive, and terminals were slow TTYs.
It's still useful if you finger fumble and get too many unexpected hits on a 
recursive find or grep.

Predates Unix by a decade - was standard on all DEC(/Digital) OSes and their 
offshoots like Tenex and Unix, the function was available in Multics tty DIM 
(whatever that stood for) - can't find any details by searching (many scanned 
docs predate useful OCR and are hundreds of pages) - may have come from MIT CTSS 
(which had many of the features and functions of Unix), the development system 
for Project MAC (the development project with many spinoffs, one of those 
Multics, another the CTSS and Multics AI Lab competitor ITS), or the 
predecessors on which they were based.

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