terminals getting killed on parent's termination

Thomas Wolff towo@towo.net
Wed Mar 10 16:30:00 GMT 2010


Andy Koppe wrote:
> 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.)
>    
Excellently pointed out. And it doesn't help the user sufficiently if 
some applications try to "do better" (as I'd say, and as I had perceived 
to be common practice) while others don't. On the other hand, the "MS 
knows best" philosophy isn't my favourite either...

>> 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.
>    
And thanks for the corresponding mintty enhancement.

>> 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. ;)
>    
Not in this case, honestly :-D
(And I checked that a 1999 Sun version of xterm had the same behaviour 
already, as do cxterm, hanterm and kterm which forked off from xterm 
quite early.)

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



More information about the Cygwin mailing list