Date: Fri, 2 Apr 1999 07:51:02 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." cc: djgpp-workers AT delorie DOT com Subject: Re: Bash ctrl-c problem simplified In-Reply-To: <199903312046.UAA50148@out4.ibm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 31 Mar 1999, Mark E. wrote: > When I compile and execute this program, I get a traceback instead of > what the documentation below (taken from signal) describes. As far as I can see, the documentation only says the special behavior is when Ctrl-C is pressed. In your case, you called `kill' instead of pressing Ctrl-C. > Does the > special SIGINT behavior only apply when the ctrl-c key is pressed or > should it also apply to kill() generated interrupts? I don't know. This behavior didn't change in v2.02: as far as I can see, v2.01 also bypassed the traceback only if Ctrl-C was pressed. We *do* want the traceback when SIGINT is generated by Ctrl-BREAK. It is easy to change the library so that *only* Ctrl-BREAK causes the traceback, but I'm not sure this is the right thing to do. For example, in the case of Bash, this would disable the traceback for Ctrl-BREAK as well, unless you do something special about Ctrl-BREAK inside Bash. So I would like comments from people about this before we decide where this should be changed. Incidentally, producing the Ctrl-C effect from a C function is very easy: just replace ``kill (getpid (), SIGINT);'' with the following snippet: __asm__ __volatile__ ("movb $0x79,%al;call ___djgpp_hw_exception");