Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!fluke!mason
From: mason@tc.fluke.COM (Nick Mason)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Ctrl-C Echo
Message-ID: <7542@fluke.COM>
Date: 3 Apr 89 14:58:13 GMT
References: <1167@optilink.UUCP>
Sender: news@tc.fluke.COM
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 26

In article <1167@optilink.UUCP> cramer@optilink.UUCP (Clayton Cramer) writes:
>I'm using signal(SIGINT, SIG_IGN) to disable control-C processing from
>an application, and it works.  But the second and third times I type
>control-C, the ^C\r\n are echoed to the screen, even though there is
>no control-C processing taking place.  Any idea who is producing the
>screen output, and how to stop it?


I'm doing something similar in my code to capture ctrl-C.  The capture
works great, but as you also found ^C\r\n is echoed to the screen.

After looking into this a great deal I believe that the echo is coming
from the BIOS and the INT9 keyboard interrupt handler.  If this is 
true then the only way to get rid of it is to write your own
keyboard handler routine.


Nick Mason/ms272G/John Fluke Mfg Co/Box C9090/Everett WA 98206 USA
   mason@tc.fluke.COM
UUCP:
 {{cornell,decvax,sdcsvax,tektronix,utcsrgv}!uw-beaver} \
{microsoft,gatech!sb1,hplabs!lbl-csam,decwrl!sun,sunup} - !fluke!mason
		 {ssc-vax,hplsla,wavetek,uw-vlsi,tikal} /
ARPA: fluke!mason@uw-beaver.ARPA
BITNET: "fluke!mason@uw-beaver.ARPA"@PSUVAX1.bitnet
"Avoid the Dull and Ignorant"