🚀 go-pugleaf

Return-Path: <chet@cwns1.ins.cwru.edu>
Date: Mon, 4 Jun 90 19:32:52 -0400
From: Chet Ramey <chet@cwns1.ins.cwru.edu>
To: rms@ai.mit.edu
Subject: Re: bug in gdb or bash
Newsgroups: gnu.bash.bug
In-Reply-To: <9006022042.AA27834@sugar-bombs.ai.mit.edu>
Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA)
Cc: bug-gdb@ai.mit.edu, chet@cwns1.ins.cwru.edu, bfox@ai.mit.edu

In article <9006022042.AA27834@sugar-bombs.ai.mit.edu> you write:
>In version 3.5 on a 386 running SysV, after the "shell" command,
>it seems that both the shell and some other process (perhaps gdb)
>try to read input at the same time.
>
>I had previously run the "more" command and killed it with C-c.
>Immediately after this, I observed the problem.

>Eventually, I was able to exit bash by typing "eexxiitt".  After the
>shell exited, gdb complained that "exit" was not a defined command.

It seems that GDB does not reset caught signals when exec-ing the shell. 
Keyboard-generated signals go to both it and bash because bash does not put
itself into a separate process group on machines without job control.  I
assume gdb jumps back to the top of its command loop upon receipt of a
SIGINT in much the same manner as bash, and both try to read another
command.

Chet

-- 
Chet Ramey				"...but worst of all, young man,
Network Services Group			 you've got Industrial Disease!"
Case Western Reserve University	
chet@ins.CWRU.Edu