Date: Wed, 14 Jan 1998 13:09:14 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
cc: djgpp AT delorie DOT com
Subject: Re: Request for comments: SIGQUIT in DJGPP v2.02
In-Reply-To: <Pine.OSF.3.95.980113143338.24898D-100000@sable.ox.ac.uk>
Message-ID: <Pine.SUN.3.91.980114130829.8730B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Tue, 13 Jan 1998, George Foot wrote:

> If the user doesn't want Ctrl-\ to abort their program, wouldn't it be
> easier to leave SIGQUIT respected but ignore the keypress, rather than
> process the Ctrl-\ keypress, generate a SIGQUIT and have it just do
> nothing?  It seems to me that the dangerous thing is Ctrl-\ generating the
> signal in a program which doesn't want that to happen, not the signal's
> existence in the first place.  Shouldn't a program be able to raise the
> signal artificially if it wants to?

I'm not sure what bothers you, exactly.

Are you bothered by a potential loss of the Ctrl-\ key because it
generates SIGQUIT (which is then ignored)?  If so, there's no problem
here, as the key is not eaten up; it stays in the keyboard controller
and *will* be seen by the BIOS keyboard handler and passed to whoever
tries to read the keyboard next.

Or are you bothered by the fact that calling "raise(SIGQUIT)" will
have no effect when the SIGQUIT handler is set to SIG_DFL?  If so,
then I don't understand why is that a problem.  If SIGQUIT is
*documented* to be ignored by default, then a program which wants
SIGQUIT to abort will need to install a handler to do that (I'm
planning on writing such a handler that users could install without
having to invent it).  It's analogous to the case of SIGWINCH
(generated on Unix when dimensions of the X window are changed): its
default action is to be discarded, and so "raise(SIGWINCH)" does
nothing.