Message-ID: <4B965367.4090402@towo.net>
Date: Tue, 09 Mar 2010 14:55:51 +0100
From: Thomas Wolff <towo AT towo DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3
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> <416096c61003051251k56e7fed6s9976b2d96bae69e7 AT mail DOT gmail DOT com>
In-Reply-To: <416096c61003051251k56e7fed6s9976b2d96bae69e7@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Andy Koppe wrote:
> Thomas Wolff:
>    
>>>> In general, a GUI application started in the background, like a terminal,
>>>> should detach itself from its parent process so that it survives if the
>>>> parent is terminated.
>>>>          
>>> Says who?
>>>        
>> Common practice in Unix/Linux/X environments.
>>      
> I've finally got round to trying to confirm this on Linux, and the
> results make me wonder what exactly you are basing this assertion on.
> Out of the terminals I tried, xterm and urxvt ignored SIGHUP, whereas
> rxvt, konsole, gnome-terminal, and lxterminal terminated. Among a
> bunch of other GUI apps, only gvim ignored SIGHUP, whereas firefox,
> gimp, abiword, konqueror and others all terminated.
>    
Thanks for this more extensive survey, comments below.

>> And user expectation that an
>> interactive session (which may e.g. contain an editing session with unsaved
>> changes...) should not be aborted by an unrelated event.
>>      
> You do have a point there (which is why mintty has the warning when
> it's closed with background processes running). Closing the terminal
> that a program was started from is not a completely unrelated event,
> though, and there might well be users that do expect everything to
> quit in that case. In other words, you don't help your case by stating
> opinion as fact and ignoring the other side of an argument.
>    
Well, I didn't mean "should" as stating a fact but more as a request for 
discussion (contributors welcome).
(Maybe one *should* be aware that the usage of "SHOULD" in RFCs may have 
somewhat tweaked the perception of "should" in computing language,
or I might have added an IMHO attribute :-) )

Concerning
> Closing the terminal that a program was started from is not a completely unrelated event,
this is also a matter of taste and use case but just using a command 
line to *start* an application does not indicate the intent that the 
command line should continue to *host* the application in the sense of a 
session.

My case is that sturdiness of an application against external impact is 
the more desirable the more interactive and potentially unsaved data it 
maintains.
This is not so much the case with browsers but at least firefox has 
introduced the feature of "Restore session" as a remedy in case it gets 
killed.
It is more the case for a shell session and even more for an editor.
Your survey above may also be interpreted this way: the most established 
terminals (xterm, rxvt-unicode) do maintain this stability, while some 
"newcomers" don't care (yet).
Among editors, apparently gvim supports my point, while emacs, gimp, 
abiword don't - but that can also just mean the issue has not received 
common awareness by now.

>> 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).
>>      
> Here we go again.
>
> My little survey showed that xterm is the only terminal that does
> things that way; all the others notify the child and quit immediately.
>    
Maybe that's why xterm is still the mainstream terminal in the X world? 
(+ IMHO + ;-) )

>> It also works with mintty but only once, due to the 'killed' flag in the
>> function child_kill in child.c
>>      
> Funnily enough, this was a deliberate design decision, i.e., a
> compromise between the two approaches. Unlike rxvt et al., it does
> allow an application to say bye and prompt about unsaved data. Yet
> unlike with xterm, a misbehaving application won't stop the user from
> closing the terminal, because guess who'd be blamed for that.
>    
A well-considered approach; however, since mintty is the only terminal 
that applies this compromise, applications cannot assume this as a 
protocol, so I doubt there is much use case.
Actually I noticed xterm also implements a useful compromise: With a 
window manager close event (Click "X", Alt-F4) it behaves as I had 
described, with "Quit" from its own menu, on the other hand, it always 
quits, thus avoiding the problem of an "unkillable" terminal.

Finally, let me discuss again my use case of embedding an application 
into a terminal ("container" model): the "HUP-delegate" protocol that I 
favour would enable a text-based command-line application to raise 
itself to a desktop application, including the option of implementing 
any application-specific "Really exit?" or "Save first?" behaviour. This 
would be another great feature of the terminal.
So please consider again these two options:
* Follow xterm like this: Apply "HUP-delegate" (i.e. forward HUP, leave 
quit decision to application) to the top-right Close button ("X"), and 
quit on Close from the menu; (Alt-F4 is not a big issue since it's 
remappable already.)
* Offer an option to apply "HUP-delegate" to "Close".

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