Mail Archives: cygwin/2010/03/09/18:40:39
Thomas Wolff:
>> 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.
That's your opinion, but apparently it's not what the designers of
either Unix or X(lib) thought, because otherwise they could have
disabled SIGHUP by default. An example of Unix's sharp-edged "the user
knows best" philosophy, I guess. (Not that I'm a great fan of that
philosophy, as I've run 'rm -r' on the wrong directory often enough.)
> My case is that sturdiness of an application against external impact is the more
> desirable the more interactive and potentially unsaved data it maintains.
Now that's something I can agree with.
> 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).
Or put another way: they've been around long enough to have had enough
complaints about it, and I do wonder whether one T.Wolff had something
to do with it. ;)
Anyway, mintty 0.6-beta3 does ignore SIGHUP, for the sake of
consistency with its behaviour when invoked from a console.
> 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.
Right. I shan't dwell on the previously mentioned "common Unix
practice in Unix/Linux/X environments".
>> [It's] 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.
True enough, but then the same is true of xterm's approach, because
many of the other terminals also identify themselves as xterm. So, as
of course you're aware, you need to check the terminal type more
closely anyway (using the 'secondary device attribute' sequence), at
which point you can pick out mintty too.
> 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.
I'd seen that too, and I think it's bad UI design to have two subtly
different ways to quit a program, whereby you have to dig deep into
the manual to even find out that there is a difference. So having the
X button and the Close menu item behave differently is out of the
question. Nor am I keen on adding an option for this.
Another way to give you what you want would be to add a control
sequence for resetting the 'killed' flag, which would stop the next
click on the close button (or menu item) from closing mintty,
Thinking about xterm again, though, Cygwin's xterm is fairly unusual
to have its menu enabled by default, i.e. the "X"/SIGHUP button often
is the only way to close it. Xterm's child process normally is a shell
that does handle SIGHUP correctly, so I guess my concern about an
unclosable terminal isn't really relevant in practice. So sod it, I'll
change mintty to xterm's approach, with the proviso that I might
revert and add the aforementioned control sequence in case it does
create issues.
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 -