Re: [PATCH] Ctrl-C and non-Cygwin programs

On Thu, Mar 29, 2012 at 11:55:51AM +0900, Ein Terakawa wrote:
>This is a proof of concept demonstration which
>makes Ctrl-C behave in a way a lot of people expect
>concerning non-Cygwin console programs.
>
>What it does actually is it generates CTRL_BREAK_EVENT with 
>Windows Console API GenerateConsoleCtrlEvent on the arrival of SIGINT.
>And to make this scheme to be functional it is required to specify
>CREATE_NEW_PROCESS_GROUP when creating new non-Cygwin processes.
>
>To my surprise there seem to be no way to generate CTRL_C_EVENT using API.
>
>I must also point out that virtually all of the terminal emulators
>are sneakily keeping hidden Windows Console in the background.

Yes, Cygwin does this by design.  It helps some programs work better if
they detect that a console is available.

>Lastly first third of the patch is a workaround of a problem observed
>with cygwin1.dll of cvs HEAD.
>To reproduce:
>1. Launch a terminal emulator like rxvt or mintty.
>2. Execute cmd.exe or more.com from shell prompt.
>3. Type in Enter, Ctrl-C, then Enter again.
>Whole processes including the terminal emulator will just hung up.

I added a fix to Cygwin a couple of days ago which was supposed to fix
this.  It just avoided trying to process a SIGINT if the user typed
CTRL-C when a non-Cygwin program had been execed.

console: new mouse modes, request/response attempt

This patch includes 2 things (to be fixed and separated anyway; change 
log still missing) for discussion:
* mouse modes 6 and 15 (numeric mouse coordinates)
* semi-fix for missing terminal status responses
The fix tries to detect the proper fhandler for CONIO, which is then 
used to queue the response.
Problem 1: I am not sure whether this detection is proper in all cases, 
what e.g. if /dev/tty is reopened etc. I don't know where else a 
relation between the handles for CONIN and CONOUT might be established.
Problem 2: While the response reaches the application with this patch, 
only the first byte is read right-away. Further bytes are delayed until 
other input is becoming present (typing a key). This may (or may not) be 
related to other issues with select(), so maybe it's worth analyzing it.

Thomas

diff -rup sav/fhandler.h ./fhandler.h
--- sav/fhandler.h	2012-04-01 19:46:04.000000000 +0200
+++ ./fhandler.h	2012-04-02 15:47:22.385727000 +0200
 <at>  <at>  -1282,8 +1282,11  <at>  <at>  class dev_console

   bool insert_mode;
   int use_mouse;
+  bool ext_mouse_mode6;
+  bool ext_mouse_mode15;
   bool use_focus;
   bool raw_win32_keyboard_mode;
+  fhandler_console * fh_tty;

Re: console: new mouse modes, request/response attempt

On Mon, Apr 02, 2012 at 08:46:31PM +0200, Thomas Wolff wrote:
>This patch includes 2 things (to be fixed and separated anyway; change 
>log still missing) for discussion:
>* mouse modes 6 and 15 (numeric mouse coordinates)
>* semi-fix for missing terminal status responses
>The fix tries to detect the proper fhandler for CONIO, which is then 
>used to queue the response.
>Problem 1: I am not sure whether this detection is proper in all cases, 
>what e.g. if /dev/tty is reopened etc. I don't know where else a 
>relation between the handles for CONIN and CONOUT might be established.
>Problem 2: While the response reaches the application with this patch, 
>only the first byte is read right-away. Further bytes are delayed until 
>other input is becoming present (typing a key). This may (or may not) be 
>related to other issues with select(), so maybe it's worth analyzing it.
>
>Thomas

>diff -rup sav/fhandler.h ./fhandler.h
>--- sav/fhandler.h	2012-04-01 19:46:04.000000000 +0200
>+++ ./fhandler.h	2012-04-02 15:47:22.385727000 +0200
> <at>  <at>  -1282,8 +1282,11  <at>  <at>  class dev_console
> 
>   bool insert_mode;
>   int use_mouse;
>+  bool ext_mouse_mode6;
>+  bool ext_mouse_mode15;
>   bool use_focus;
>   bool raw_win32_keyboard_mode;
>+  fhandler_console * fh_tty;
> 

Re: console: new mouse modes, request/response attempt

Am 02.04.2012 20:50, schrieb Christopher Faylor:
> On Mon, Apr 02, 2012 at 08:46:31PM +0200, Thomas Wolff wrote:
>> This patch includes 2 things (to be fixed and separated anyway; change
>> log still missing) for discussion:
>> * mouse modes 6 and 15 (numeric mouse coordinates)
>> * semi-fix for missing terminal status responses
>> The fix tries to detect the proper fhandler for CONIO, which is then
>> used to queue the response.
>> Problem 1: I am not sure whether this detection is proper in all cases,
>> what e.g. if /dev/tty is reopened etc. I don't know where else a
>> relation between the handles for CONIN and CONOUT might be established.
>> Problem 2: While the response reaches the application with this patch,
>> only the first byte is read right-away. Further bytes are delayed until
>> other input is becoming present (typing a key). This may (or may not) be
>> related to other issues with select(), so maybe it's worth analyzing it.
>>
>> Thomas
>> diff -rup sav/fhandler.h ./fhandler.h
>> --- sav/fhandler.h	2012-04-01 19:46:04.000000000 +0200
>> +++ ./fhandler.h	2012-04-02 15:47:22.385727000 +0200
>>  <at>  <at>  -1282,8 +1282,11  <at>  <at>  class dev_console
>>
>>    bool insert_mode;
>>    int use_mouse;
>> +  bool ext_mouse_mode6;
>> +  bool ext_mouse_mode15;
>>    bool use_focus;
>>    bool raw_win32_keyboard_mode;
>> +  fhandler_console * fh_tty;
>>

Re: console: new mouse modes, request/response attempt

On Mon, Apr 02, 2012 at 09:50:17PM +0200, Thomas Wolff wrote:
>Am 02.04.2012 20:50, schrieb Christopher Faylor:
>> On Mon, Apr 02, 2012 at 08:46:31PM +0200, Thomas Wolff wrote:
>>> This patch includes 2 things (to be fixed and separated anyway; change
>>> log still missing) for discussion:
>>> * mouse modes 6 and 15 (numeric mouse coordinates)
>>> * semi-fix for missing terminal status responses
>>> The fix tries to detect the proper fhandler for CONIO, which is then
>>> used to queue the response.
>>> Problem 1: I am not sure whether this detection is proper in all cases,
>>> what e.g. if /dev/tty is reopened etc. I don't know where else a
>>> relation between the handles for CONIN and CONOUT might be established.
>>> Problem 2: While the response reaches the application with this patch,
>>> only the first byte is read right-away. Further bytes are delayed until
>>> other input is becoming present (typing a key). This may (or may not) be
>>> related to other issues with select(), so maybe it's worth analyzing it.
>>>
>>> Thomas
>>> diff -rup sav/fhandler.h ./fhandler.h
>>> --- sav/fhandler.h	2012-04-01 19:46:04.000000000 +0200
>>> +++ ./fhandler.h	2012-04-02 15:47:22.385727000 +0200
>>>  <at>  <at>  -1282,8 +1282,11  <at>  <at>  class dev_console
>>>
>>>    bool insert_mode;
>>>    int use_mouse;
>>> +  bool ext_mouse_mode6;
>>> +  bool ext_mouse_mode15;
>>>    bool use_focus;
>>>    bool raw_win32_keyboard_mode;
>>> +  fhandler_console * fh_tty;

[PATCH] Mouse reporting modes 1006 and 1015 for extended coordinates

This patch implements mouse modes 1006 and 1015 for the cygwin console 
(no experimental add-ons this time :) ).
They enable unlimited mouse coordinate reporting like recent xterm, 
mintty, urxvt. If someone is interested, I could also implement mouse 
mode 1005.
Thomas

2012-04-03  Thomas Wolff  <towo <at> towo.net>

	* fhandler.h (class dev_console): Two flags for extended mouse modes.
	* fhandler_console.cc (fhandler_console::read): Implemented 
	extended mouse modes 1015 (urxvt, mintty, xterm) and 1006 (xterm).
	Not implemented extended mouse mode 1005 (xterm, mintty).
	Supporting mouse coordinates greater than 222 (each axis).
	Also: two { wrap formatting consistency fixes.
	(fhandler_console::char_command) Initialization of enhanced 
	mouse reporting modes.

diff -rup sav/fhandler.h ./fhandler.h
--- sav/fhandler.h	2012-04-01 19:46:04.000000000 +0200
+++ ./fhandler.h	2012-04-03 15:52:07.893561600 +0200
 <at>  <at>  -1282,6 +1282,8  <at>  <at>  class dev_console

   bool insert_mode;
   int use_mouse;
+  bool ext_mouse_mode6;
+  bool ext_mouse_mode15;

Re: console: new mouse modes, request/response attempt

Am 02.04.2012 22:40, schrieb Christopher Faylor:
> On Mon, Apr 02, 2012 at 09:50:17PM +0200, Thomas Wolff wrote:
>> Am 02.04.2012 20:50, schrieb Christopher Faylor:
>>> On Mon, Apr 02, 2012 at 08:46:31PM +0200, Thomas Wolff wrote:
>>>> ...
>>>> * semi-fix for missing terminal status responses
>>>> The fix tries to detect the proper fhandler for CONIO, which is then
>>>> used to queue the response.
>>>> Problem 1: I am not sure whether this detection is proper in all cases,
>>>> what e.g. if /dev/tty is reopened etc. I don't know where else a
>>>> relation between the handles for CONIN and CONOUT might be established.
>>>> Problem 2: While the response reaches the application with this patch,
>>>> only the first byte is read right-away. Further bytes are delayed until
>>>> other input is becoming present (typing a key). This may (or may not) be
>>>> related to other issues with select(), so maybe it's worth analyzing it.
>>>>
>>>> Thomas
>>>> diff -rup sav/fhandler.h ./fhandler.h
>>>> --- sav/fhandler.h	2012-04-01 19:46:04.000000000 +0200
>>>> +++ ./fhandler.h	2012-04-02 15:47:22.385727000 +0200
>>>>  <at>  <at>  -1282,8 +1282,11  <at>  <at>  class dev_console
>>>>
>>>>     bool insert_mode;
>>>>     int use_mouse;
>>>> +  bool ext_mouse_mode6;
>>>> +  bool ext_mouse_mode15;
>>>>     bool use_focus;
>>>>     bool raw_win32_keyboard_mode;
>>>> +  fhandler_console * fh_tty;
>>>>

Re: [PATCH] Setting TZ may break time() in non-Cygwin programs

On Mar 4, Corinna Vinschen wrote:
> On Mar  4 19:42, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>> On Mar  2 22:35, Christian Franke wrote:
>>>> Corinna Vinschen wrote:
>>>>> But, as usual, PTC.
>>>> OK, ...
>>>>
>>>>> Simple: Unset TZ for Win32 programs run from Cygwin.
>>>>>
>>>>> More flexible: Set (unset) TZ=CYGWIN_WINENV_TZ if this variable is
>>>>> set (to empty). Otherwise keep TZ as is.
>>>>>
>>>> would a patch for any of the above have a chance to get accepted?
>>> If it's not getting too complicated, yes.  However, the second idea
>>> I don't understand.  Can you explain this differently?
>>>
>> Let another variable change the value passed to Windows environment:
>>
>> $ printenv TZ
>> Europe/Berlin
>>
>> $ cmd /c echo %TZ%
>> Europe/Berlin
>>
>> $ export CYGWIN_WINENV_TZ=CET-1CEST
>>
>> $ printenv TZ
>> Europe/Berlin
>>

Re: [PATCH] Setting TZ may break time() in non-Cygwin programs

Hi Christian,

On Apr 11 20:52, Christian Franke wrote:
> Yes. Patch is attached.
> 
> Christian
> 

Thanks for the patch.  I'm just wondering if we shouldn't generalize
this right from the start by keeping an array of variables to skip
when starting native apps and a function to handle this, along the
lines of the getwinenv function and the conv_envvars array.
It might only contain TZ now, but there's always a chance we suddenly
stumble over a similar problem, isn't it?

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Re: [PATCH] Setting TZ may break time() in non-Cygwin programs

On Tue, Apr 17, 2012 at 09:06:15AM +0200, Corinna Vinschen wrote:
>On Apr 11 20:52, Christian Franke wrote:
>> Yes. Patch is attached.
>> 
>> Christian
>> 
>
>Thanks for the patch.  I'm just wondering if we shouldn't generalize
>this right from the start by keeping an array of variables to skip
>when starting native apps and a function to handle this, along the
>lines of the getwinenv function and the conv_envvars array.
>It might only contain TZ now, but there's always a chance we suddenly
>stumble over a similar problem, isn't it?

I really hate having Cygwin be "smart" like this.  It seems like it's
asking for a follow-on "How do I set TZ for my Windoze program???"
email, followed by a "We need a CYGWIN environment variable option!"

What's the problem with just unsetting TZ again?  Yes, I know you
have to remember to do it but does this affect enough programs that
we need to add even more head standing code in Cygwin to accommodate
it.

cgf