X-Spam-Check-By: sourceware.org
From: Simon Marlow <simonmar AT microsoft DOT com>
To: Brian Dessent <brian AT dessent DOT net>
CC: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date: Mon, 4 Dec 2006 12:13:00 +0000
Subject: RE: Ctrl-C and non-cygwin programs
Message-ID: <A50988F69402FB47B4D860B67FB51FA13462FCAF@EA-EXMSG-C311.europe.corp.microsoft.com>
In-Reply-To: <456F0753.78B7CC9B@dessent.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id kB4CDJlD023662

Brian Dessent wrote:
> Simon Marlow wrote:
>
>> Then run the program, hit Ctrl-C and see what happens.  The
> behaviour differs depending on the environment:
>>
>>   * In a Cygwin shell started from cygwin.bat, with the CYGWIN
>>     environment variable empty: correct behaviour, Ctrl-C is caught
>> and handled.
>>
>>   * In a Cgwin shell started from cygwin.bat, with CYGWIN=tty:
>>     Ctrl-C apparently just kills the child process, the event is
>> not caught.
>>
>>   * In an xterm (Cygwin), with Cygwin bash: again, the child process
>> is just killed.
>>
>>   * In a CMD.EXE shell, Ctrl-C is caught and handled.
>
> The problem is that in the case of CYGWIN=tty or under xterm/rxvt, the
> program is not attached to a Windows console at all.  It is running
> under a Cygwin pseudoterminal (pty), which to a non-Cygwin
> app will look
> as if it was totally detached with just pipes connected to stdin and
> stdout.  Since there's no console, there's no way for a
> ConsoleCtrlHandler event to fire.

Ok, thanks.  So the bit I didn't realise was that a process needs to be attached to an actual Windows console in order to get Ctrl-C events.  This is a bit of a problem, because it essentially means that a Cygwin shell running in either CYGWIN=tty mode or in an xterm cannot behave like a Windows shell for invoking non-cygwin console programs.  Any console program that relies on being able to catch Ctrl-C to clean up cannot be used reliably from an xterm.

This is a shame, because I really like using Cygin xterm under windows - its terminal behaviour seems a lot more reliable than the Cygwin bash console.  Incedentally, what does bash do to the child process when it detects Ctrl-C and there's no console?  TerminateProcess()?

I have one suggestion: could this be documented somewhere please?  I spent a lot of time searching mailing lists and documentation for the answer to this question, but didn't find it anywhere.  Apologies if I missed it.

Cheers,
        Simon

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/