Mail Archives: djgpp-workers/1998/01/19/20:38:13
On Sun, 18 Jan 1998, Markus F.X.J. Oberhumer wrote:
> - because many programs currently install SIGQUIT handlers out of
> paranoia, but none of them *wants* to receive SIGQUIT
The question is not whether a program does or doesn't want to receive
SIGQUIT. The question is whether it will break something. If it doesn't
break anything important, it should IMHO be included because it is
supported on POSIX platforms.
I fail to see how a program which installs a handler for SIGQUIT can be
broken by getting SIGQUIT. If you have an example of such a program, or
can imnagine such a situation, please tell me the details so I could think
about the possible problems.
> - because SIGQUIT keys are highly localized - I have to press
> the following 3 keys on my German keyboard (thanks Tom):
> Ctrl + AltGr (this is the right Alt) + sharp s (which is the '-' next
> to the '0' on an US keyboard)
No, that's not how it works. The DJGPP keyboard handler works with scan
codes, not ASCII codes. So you get SIGQUIT when you press Ctrl and a key
whose scan code is 2Bh (unless you change the scan code which triggers
SIGQUIT by calling `__djgpp_set_sigquit_key').
> - because I'm not sure what is good for ;-) - why do yo need it,
> and why do you think that many programs need it ?
IMHO the question is not what is it good for, but how bad is it not to
support it.
a. SIGQUIT is POSIX. It's IMHO bad not to support POSIX features which
can be reasonably supported.
b. I saw two programs which use it. Any program which installs two
different handlers for SIGINT and SIGQUIT, with two different actions,
is impossible to port without some SIGQUIT support (short of installing
a customized hardware keyboard interrupt handler).
- Raw text -