X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Message-ID: <4B90E4BC.5050808@towo.net> Date: Fri, 05 Mar 2010 12:02:20 +0100 From: Thomas Wolff User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: terminals getting killed on parent's termination References: <201002261446 DOT o1QEki2k024924 AT mail DOT bln1 DOT bf DOT nsn-intra DOT net> <416096c61002261229j31f92387u8b8e3e9b716cb131 AT mail DOT gmail DOT com> <4B8BEACA DOT 4010003 AT towo DOT net> <416096c61003032349h6f22d223v7aa03c07f4f27475 AT mail DOT gmail DOT com> In-Reply-To: <416096c61003032349h6f22d223v7aa03c07f4f27475@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 04.03.2010 08:49, Andy Koppe wrote: > Thomas Wolff: > >> Andy Koppe: >> >>> Mintty has default handling for SIGHUP, i.e. it exits. >>> >> Actually (another topic but related) mintty has a great feature here: it >> passed the SIGHUP to its client application and if that application catches >> and handles the SIGHUP, mintty does *not* exit. >> > I don't think that's true. See signal_thread() in child.c: if mintty > receives a SIGINT, SIGTERM, or SIGHUP, it sends a SIGHUP to the child > process to say that the terminal is disappearing and then exits > immediately. > > (I'm not convinced that sending the SIGHUP manually should be > necessary actually, i.e. I'd have expected SIGHUP to automatically be > sent to attached processes when the master side of the pty is closed > due to mintty exiting. But I haven't got 'round to look into this > properly.) > > > >> This enables an application >> to be embedded into mintty as a terminal container and implement some >> reasonable "Really exit?" behaviour with the option not to exit. >> I suspect though, that this feature might not be on purpose since the >> semantics of SIGHUP would be slightly tweaked here. Anyway, it's very >> useful, so I'd like to ask to please make it a defined feature to rely on >> > This conflicts with your request for mintty to ignore SIGHUP. > Actually there are two different scenarios here which I didn't describe clearly: 1. Termination of a terminal's parent. This should not abort the terminal session, whether or not the notification mechanism is HUP. (In the case console -> xterm you said it's due to console attachment, whatever that means in detail.) 2. Manual termination of a terminal with a window manager operation (like clicking the Close X button, selecting Close from the menu, pressing Alt-F4). In the case of a Windows application, this is a WM_CLOSE message being handled (not a HUP as I had assumed). If the direct child process of the terminal explicitly catches HUP, the terminal should not terminate. It should just send HUP to its child and then terminate only if the child terminates (overriding a "hold after command terminates" option in this case, so the option can be reset when handling this). This works fine with xterm. It also works with mintty but only once, due to the 'killed' flag in the function child_kill in child.c. Should I propose a patch? Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple