Mail Archives: cygwin/2010/03/05/15:52:03
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.
> 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.
> 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.
> 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.
> Should I propose a patch?
Not much point, because the difficult bit here is design not implementation.
Andy
--
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
- Raw text -