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

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

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