Thread View: gnu.bash.bug
2 messages
2 total messages
Started by Terry Hull
Wed, 24 Jan 1990 20:06
Bash Script not terminating on SystemV
Author: Terry Hull
Date: Wed, 24 Jan 1990 20:06
Date: Wed, 24 Jan 1990 20:06
15 lines
1251 bytes
1251 bytes
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
Re: Bash Script not terminating on SystemV
Author: Chet Ramey
Date: Wed, 24 Jan 1990 22:38
Date: Wed, 24 Jan 1990 22:38
47 lines
2935 bytes
2935 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads