Thanks a lot Igor!! Just sent out a question to [EMAIL PROTECTED]
In the meantime I found out that everything works with my old TCSH version tcsh 6.12.00 (Astron) 2002-07-23 (i386-intel-posix) options 8b,nls,dl,al,rh,color Since I'm quite busy at the moment, I need to wait with any further research until I get a bugfix for the new version. Thanks and best regards BSE > On Thu, 17 Jun 2004, "Else Böse" wrote: > > > ... snip ... > > > > > So it lets you close the window, and the tcsh process doesn't linger > on? > > > > Mmmmh, seems not to be the case. I just checked my process list and saw > lots > > of "I" marked processes, e.g. > > > > I 504 1 504 4012 15 11369 22:41:02 /usr/bin/tcsh > > Else, > > The "I" is normal - it just means that the process is in the "waiting for > input" state. You'll see it also on bash and sh processes that aren't the > current shell. What's not normal is the fact that the process doesn't > have a parent, and is left over after rxvt closes (this, BTW, may also be > a bug in rxvt). > > > This one remained after I closed my last rxvt. > > What does this mean? > > > > > > > The next is to try attaching to tcsh with a debugger and seeing if > it > > > > > gets any signals from the xterm as it gets closed (it should get > at > > > > > least a SIGHUP). > > > > > > > > Good idea! > > > > I also thought that it must have to do with this, at least from > > > > looking at the strace output after doing ALT+F4 : > > > > > > > > 43394846 44791043 [main] xterm 4000 kill_pgrp: pid 3824, signal 1 > > > > 1670 44792713 [main] xterm 4000 kill_pgrp: killing pid 3824, pgrp > 3824, p->ctty 16, myself->ctty 0 > > > > 58 44792771 [main] xterm 4000 sig_send: sendsig 0x524, pid 3824, > signal 1, its_me 0 > > > > 31 44792802 [main] xterm 4000 sig_send: Not waiting for > sigcomplete. its_me 0 signal 1 > > > > 15466960 43593591 [sig] -csh 3824 sigpacket::process: signal 1 > processing > > > > 58 43593649 [sig] -csh 3824 sigpacket::process: signal 1 blocked > > > > 18 43593667 [sig] -csh 3824 sigpacket::process: returning -1 > > > > 121 44792923 [main] xterm 4000 sig_send: returning 0x0 from > sending signal 1 > > > > > > > > From this it seems that tcsh does not accept signal 1 (SIGHUP). > > > > Any ideas why? > > > > > > Nope. But the same signal should have been sent from both rxvt and a > > > console window (if you run tcsh in those). One thing to do would be > to > > > strace both of those, and compare the relevant chunks of the output. > > > > > > > Thanks for any further hints. > > > > > > > > BSE > > > > > > Another thing I thought of is trying to send the signal to tcsh > > > explicitly, using the "kill -1" command. See if that works, and if it > > > does, see how the strace output differs. > > > > Here comes the strace using kill -1 > > > > 45779212 55756681 [sig] -csh 5064 sigpacket::process: signal 1 > processing > > 87 55756768 [sig] -csh 5064 sigpacket::process: signal 1 blocked > > 18 55756786 [sig] -csh 5064 sigpacket::process: returning -1 > > 58 55756844 [sig] -csh 5064 sigpacket::process: signal 19 processing > > 35 55756879 [sig] -csh 5064 sigpacket::process: default signal 19 > ignored > > 17 55756896 [sig] -csh 5064 sigpacket::process: returning 1 > > > > Looks pretty similar to the above, or? > > Seems you're right. It has to do with tcsh not accepting SIGHUPs. > > I think we can reliably reproduce this, and it's independent of any X > applications (i.e., I've reproduced this on my machine with a tcsh running > in a console window, and sending it a SIGHUP). > > > But how could I change this? > > I looked into /etc/csh.login and /etc/csh.cshrc and removed also my > > ~/.cshrc. No evidence except that in /etc/csh.cshrc the interrupts are > > disabled by default using 'onintr -'. I removed that but have still the > same > > problem. > > > > Further ideas? > > Well, now that it's reproducible outside of X, you should probably report > this on the main Cygwin list as a tcsh problem (I'd make it a full initial > report, with an attached cygcheck output, etc, although you can refer to > this thread in the archives[*]). FWIW, I seem to recall that tcsh worked > fine for me in the past (I'm a bash user, so I wouldn't have noticed this > problem). It may be a bug in tcsh that manifested with the new Cygwin > DLL, or a bug in the new version of Cygwin. If you're willing to help the > maintainer out and do some debugging, you could try to build tcsh from > source and debug info. Good luck! > Igor > [*] <http://cygwin.com/ml/cygwin-xfree/2004-06/msg00142.html> > -- > http://cs.nyu.edu/~pechtcha/ > |\ _,,,---,,_ [EMAIL PROTECTED] > ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] > |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. > '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! > > "I have since come to realize that being between your mentor and his route > to the bathroom is a major career booster." -- Patrick Naughton > -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info