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
