SIGINT and bash on Sys5

Thread View: gnu.bash.bug

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Ian G Batten Wed, 02 Aug 1989 13:36

#409

Author: Ian G Batten
Date: Wed, 02 Aug 1989 13:36

21 lines
1350 bytes

I reported earlier today an interaction between Emacs and Bash on System V.
We investigated further and found the problem occurred with all SIGINTs.
If multiple shells were run from each other and then ``cat'' was run, a
Control-C to cat got a prompt from EACH shell stacked up and possibly
killed the top one.

[Parenthetically, I did a symptomatic patch to emacs by only using SIGQUIT
for ^G handling, rather than SIGQUIT and SIGINTR.  This is harmless, and
I may suggest it to the emacs maintainers].

Because a SIGINT will be delivered to all processes associated with the
terminal, the behaviour above is reasonable.  I have set the handler for
SIGINT to SIG_IGN on the parent side, and reset it later, around the 
wait in nojobs.  This fixes the immediate problem, and allows vi etc
to work, but I suspect  it will cause more problems.

This is bash 1.02 on V.3.2.  I'd like to hear from other people using bash
on S5.

ian

bash1.02 on Iris 4d anyone?

#412

Author: Jean-Francois Lamy
Date: Thu, 03 Aug 1989 00:04

5 lines
593 bytes

Does anyone have diffs for bash1.02 on Iris 4D machines?  Lose nothing by
asking...

Jean-Francois Lamy               lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy
AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4

Re: SIGINT and bash on Sys5

#419

Author: Jeff Barr
Date: Thu, 03 Aug 1989 21:46

34 lines
1647 bytes

In article <13695.8908021336@holly.fulcrum.bt.co.uk>, igb@fulcrum.british-telecom.co.uk (Ian G Batten) writes:
> 
> I reported earlier today an interaction between Emacs and Bash on System V.
> We investigated further and found the problem occurred with all SIGINTs.
> If multiple shells were run from each other and then ``cat'' was run, a
> Control-C to cat got a prompt from EACH shell stacked up and possibly
> killed the top one.
> 

I don't know anything about Bash, but this is a symptom of the shell not
putting child processes in their own process group.  The terminal driver
sends the Interrupt signal to all processes in the highest process group
(and some other condition), not to all processes of the terminal.  

Code similar to the following is needed when running child processes:

	if (p = fork ())
		/* parent side */
	else
	{
	  setpgrp ();

	  exec (.....);
	}

On Berkeley systems, setpgrp needs an argument.

Not having seen or used Bash, this may be totally wrong........ :-(.

						Jeff

  /\       Jeff Barr   \    / Visix Software, Inc.  /\  800-832-8668 \    /  
 /  \  uunet!visix!jeff \  /   1525 Wilson Blvd.   /  \ 703-841-5858  \  /
/    \                   \/   Arlington, VA 22209 /    \               \/

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