cramer@optilink.UUCP (Clayton Cramer) (04/01/89)
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?
--
Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer
Sad but true: the three most powerful emotions are greed, fear, and hatred.
----------------------------------------------------------------------------
Disclaimer? You must be kidding! No company would hold opinions like mine!mason@tc.fluke.COM (Nick Mason) (04/03/89)
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"
vlruo02@dutrun.UUCP (Ge van Geldorp) (04/04/89)
In article <7542@fluke.COM> mason@tc.fluke.COM (Nick Mason) writes: >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. It's the CON device driver which writes the ^C\r\n. The good news is that there are ways to avoid this. If you want to disable Ctrl-c completely, get the <MSDOS.C>CTRL-C.C package from SIMTEL20. The routines in this package (which was written by John Galvin, galvin@circle.UUCP) basicly put the CON device in raw mode, using dos function 0x44 (IOCTL). If you want to act upon ctrl-c, but have the ^C\r\n suppressed, things are slightly more difficult. The ^C\r\n string is written to standard output. If you can do without standard output, open the NUL device. Use the file descriptor obtained from this call with a dup2 call to have stdout redirected to NUL. Now, the CON driver can write ^C\r\n if it wants to, but it won't end on your screen. Code fragment: int nulfh; nulfh = open("nul", O_WRONLY, 0644); /* get new file descriptor */ fflush(stdout); /* flush any remaining chars */ dup2(nulfh, 1); /* redirect stdout to NUL */ close(nulfh); /* clean up */ Hope this helps. Ge van Geldorp. (...!mcvax!hp4nl!dutrun!vlruo02)
huang@stiatl.UUCP (Jim Huang) (04/04/89)
Try to set all devices ( stdin, stdout, stderr, lpr, com ) to raw mode. It will stop ^C dispaly.