headers
Ein Terakawa | 29 Mar 2012 04:55
Picon

[PATCH] Ctrl-C and non-Cygwin programs

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.
Thus several features of the Windows Console is still available to
processes running in the cygwin environment.
One of such features is this 'process group' and the other one is
'code page' which you manipulate with chcp.com utility.

Following is a bunch of random posts, I picked up from this list, 
talking about the same topic. Ordered by its significance under my judge.
These should help you understand (or remind) what it is about.

Date: Mon, 04 Dec 2006 06:24:41 -0800
Subject: Re: Ctrl-C and non-cygwin programs
http://cygwin.com/ml/cygwin/2006-12/msg00151.html

Date: Thu, 20 May 2010 22:50:49 +0000 (UTC)
Subject: A workaround for CTRL-C not working on Windows console apps in ptys
http://sourceware.org/ml/cygwin/2010-05/msg00524.html
(Continue reading)

Permalink | Reply |
headers
Ryan Johnson | 29 Mar 2012 05:24
Picon
Picon
Favicon

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

On 28/03/2012 10:55 PM, Ein Terakawa wrote:
> 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.
Interesting... I may have just hit this earlier today trying to run a
Java program inside mintty. I assumed it was just Java being weird,
since killing it releases the terminal.

I'll try to build a cygwin1.dll with the patch, but my source tree seems
to be in a bad state so it could be a while.

Ryan
Permalink | Reply |
headers
Christopher Faylor | 2 Apr 2012 00:45
Favicon

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.
(Continue reading)

Permalink | Reply |

Gmane