miw@mucs.UX.CS.MAN.AC.UK (Mario Wolczko) (09/03/87)
I've just finished installing X 10.4 on a SUN-3 system (SunOS3.2), and everything was fine, but: whenever I open an xterm window within uwm or menuwm, either from a menu or by something like "xterm &", the INT and QUIT signals are ignored within that window. More specifically, I can't stop anything with ^C or ^\. These still work OK within the login window, and ^Z works fine everywhere, so I can do something like ^Z-k-i-l-l- -% to kill things. After checking the setting of the terminal, and lots of other obsure things, the only thing I can conclude from looking at the code is that INT and QUIT are being set to SIG_IGN when I start either xterm or the window manager with an &, and nothing is re-enabling them. To prove this, I added two lines to both xterm and menuwm, namely signal(SIGINT, SIG_DFL); signal(SIGQUIT, SIG_DFL); just before each execs a program. This seems to cure the problem. Has anyone else encountered this? Surely everybody who uses X doesn't put up with this behaviour! Mario Wolczko ------------------------------------------------------------------------ Dept. of Computer Science ARPA: miw%ux.cs.man.ac.uk The University USENET: mcvax!ukc!man.cs.ux!miw Manchester M13 9PL JANET: miw@uk.ac.man.cs.ux U.K. +44-61-273 7121 x 5699 ------------------------------------------------------------------------
ken@cs.rochester.edu (Ken Yap) (09/05/87)
I saw this before with a user here. What are you starting up the xterm with? If it is a sh script with &, then remember sh disables interrupt and quit for backgrounded processes. This ignore gets inherited by the children. Apparently csh resets before spawning so csh scripts are ok. Ken
ken@cs.rochester.edu (Ken Yap) (09/05/87)
In article <1894@sol.ARPA> I wrote: |I saw this before with a user here. What are you starting up the xterm |with? If it is a sh script with &, then remember sh disables interrupt |and quit for backgrounded processes. This ignore gets inherited by the |children. Apparently csh resets before spawning so csh scripts are ok. Ken, you twit, you shouldn't post articles before breakfast. Ignore previous distortion of truth. The user in question was starting up xterm with a backgrounded sh script. He was also the rare "/bin/sh login shell" user in our department. Since the backgrounded sh script had SIGINT and SIGQUIT turned off, his xterm sh was ignoring these. Csh, on the other hand, turns on SIGINT and SIGQUIT catching when it starts up as an interative shell. So the other (csh) users never encountered any problem. Xtools users also had no problems with either login shell. So, do you have this combination: xterm started from a sh script with & and a login shell of /bin/sh? Think I got it right now. Feel better with 3 fresh bagels in my tummy. Ken
miw@mucs.UX.CS.MAN.AC.UK (Mario Wolczko) (09/07/87)
>In article <1894@sol.ARPA> I wrote: >|I saw this before with a user here. What are you starting up the xterm >|with? If it is a sh script with &, then remember sh disables interrupt >|and quit for backgrounded processes. This ignore gets inherited by the >|children. Apparently csh resets before spawning so csh scripts are ok. > >Ken, you twit, you shouldn't post articles before breakfast. Ignore >previous distortion of truth. > >The user in question was starting up xterm with a backgrounded sh >script. He was also the rare "/bin/sh login shell" user in our >department. Since the backgrounded sh script had SIGINT and SIGQUIT >turned off, his xterm sh was ignoring these. Csh, on the other hand, >turns on SIGINT and SIGQUIT catching when it starts up as an interative >shell. So the other (csh) users never encountered any problem. Xtools >users also had no problems with either login shell. > >So, do you have this combination: xterm started from a sh script with & >and a login shell of /bin/sh? Got it (nearly) in two! I start xterm in one of two ways: 1. Automatically when I log in, with a shell script that is run from xinit, and, 2. From a menu in menuwm, using the line: shell: !"xterm" in my .menuwmrc. As you correctly guessed I'm a Bourne man (actually, a Bourne-derivative man, with job control and history [much nicer than csh, but let's not get into that one]). So it would seem that most of the world's X-users are also csh users, and haven't encountered the problem before. Q. Which program (xterm or shell) is wrong? Should interactive programs always turn SIGINT and SIGQUIT back on? My feeling is that there are many programs that don't care whether they're interactive or not, and could possibly be used as "shells", so that xterm and menuwm (and uwm too) are at fault here. Still, I've fixed the problem now, so I'm not too bothered either way. Mario ------------------------------------------------------------------------ Dept. of Computer Science ARPA: miw%ux.cs.man.ac.uk The University USENET: mcvax!ukc!man.cs.ux!miw Manchester M13 9PL JANET: miw@uk.ac.man.cs.ux U.K. +44-61-273 7121 x 5699 ------------------------------------------------------------------------