Date: Mon, 5 Jan 1998 19:05:14 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc: djgpp-workers AT delorie DOT com, dj AT delorie DOT com
Subject: Re: djgpp v2.02 alpha 980101
In-Reply-To: <m0xp7wf-000S2YC@inti.gov.ar>
Message-ID: <Pine.SUN.3.91.980105185957.768A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Mon, 5 Jan 1998, Salvador Eduardo Tropea (SET) wrote:

> RHIDE (and my editor) can be affected. Currently I dissable Ctrl+C and I can 
> make the same for it

You don't need to do anything special, if you already disable Ctrl-C, 
because the new library will disable both Ctrl-C and Ctrl-\ when you do 
that.

> > The reason I don't like having SIGQUIT disabled by default is that it
> > will require DJGPP-specific code to switch it on in programs that do
> > want to catch SIGQUIT differently than SIGINT (yes, I have examples of
> > such programs).
> But if that's a flag I think isn't a problem because these flags are used to 
> setup some features. I for example use the flag to enable multiple commands 
> in system() calls, isn't that common in UNIX programs?

I don't understand what exactly are you telling here.  Please explain.

The problem that I was trying to relate is how the decision about 
enabling SIGQUIT should be done.  I would like to avoid DJGPP-specific 
code that needs to be added to ported programs that need to catch 
SIGQUIT.  Setting a flag requires such DJGPP-specific code.  The fact 
that `system' already requires such DJGPP-specific code doesn't mean we 
need to do the same for SIGQUIT.