terry@eecea.eece.ksu.edu (Terry Hull) (01/25/90)
I have been having trouble with shell scripts not terminating when they receive an interrupt using bash-1.04 with Chip Salzenburg's patches installed on SCO UNIX, so I decided to try to get bash to run on an AT&T 3B15 to see how it worked there. Well the 3B15 does not have a sigignore, so I defined it out in nojobs.c. I was then able to get it compiled and the interrupt signal worked correctly on the 3B15. Well, I decided to try this fix on SCO UNIX, and it solved the problem there too. Why is the sigignore(SIGINT) in the wait_for() function in nojobs.c? What did I break by removing it? -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: terry@tah386.manhattan.ks.us, rutgers!ksuvax1!eecea!tah386!terry
chet@cwns1.CWRU.EDU (Chet Ramey) (01/25/90)
In article <948@eecea.eece.ksu.edu> terry@eecea.eece.ksu.edu (Terry Hull) writes: >I have been having trouble with shell scripts not terminating when >they receive an interrupt using bash-1.04 with Chip Salzenburg's >patches installed on SCO UNIX, so I decided to try to get bash to run >on an AT&T 3B15 to see how it worked there. Well the 3B15 does not >have a sigignore, so I defined it out in nojobs.c. I was then able to >get it compiled and the interrupt signal worked correctly on the 3B15. >Well, I decided to try this fix on SCO UNIX, and it solved the problem >there too. Why is the sigignore(SIGINT) in the wait_for() function in >nojobs.c? What did I break by removing it? Well, I don't have a System V machine to play with, but I'll take a crack at this one. The System V kernel is sending the SIGINT to at least the foreground process and the shell. The terminal driver (termio(7)) sends the interrupt to `all processes with the associated control terminal', which is the process group associated with that terminal. So, unless a process has dissociated itself from its control terminal by becoming a process group leader via setpgrp(), it will get the SIGINT. This includes (at least) the foreground process and the shell itself. Processes begun in the background ignore SIGINT and SIGQUIT, so they typically will be immune to keyboard interrupts. The foreground process is dying, and the shell is at some later point doing a throw_to_top_level or the equivalent (parse_and_execute does its own magic with interrupts). Now that you're not ignoring the signal, it can get through to the shell, and the shell is behaving as you expect. One possible complication is that typing ^C to a program that is ignoring interrupts could cause the shell to get confused. This probably wouldn't happen, because of the use of the QUIT macro to delay interrupt handling until it's `safe', but it's possible. jobs.c has code that does essentially a `kill(getpid(), SIGINT)' when job control is active and it notices that a child has died from an interrupt, but only because the top level shell, being in a different process group, didn't get the signal itself. This should probably be considered a bug in nojobs.c. Chet Ramey -- Chet Ramey "Can't you pay a grad student to Network Services Group read the manual for you?" Case Western Reserve University -- Bill Wisner, chet@ins.CWRU.Edu to Peter Honeyman