From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from odin.INS.CWRU.Edu ([129.22.8.102]) by archone.tamu.edu with SMTP id <45321>; Tue, 21 Apr 1992 18:17:56 -0500
Received:  by odin.INS.CWRU.Edu (5.65b+ida+/CWRU-1.5-ins)
	id AA12422; Tue, 21 Apr 92 15:15:16 -0400 (from chet for /usr/homes/chet/bin/mailfilter.sh /usr/homes/chet/mbox)
Date: Tue, 21 Apr 1992 13:36:44 -0500
From: Chet Ramey <chet@odin.INS.CWRU.Edu>
To: culliton@srg.af.mil
Subject: Re: rc and readline and SIGINT
Cc: rc@archone.tamu.edu, chet@odin.INS.CWRU.Edu
Reply-To: chet@po.CWRU.Edu
In-Reply-To: Message from culliton@srg.af.mil of Fri, 17 Apr 1992 16:52:51 -0500
Message-Id: <9204211836.AA11917.SM@odin.INS.CWRU.Edu>
Read-Receipt-To: chet@po.CWRU.Edu

> Well, I'm going to throw this one open to everyone and maybe someone like
> Chet will read it and come up with a good answer.

OK, here goes.

rc and bash manage signals very similarly.  The regular signal handler simply
sets a flag noting that the signal occurred, and the handler is run when it
is convenient to do so.  So far, so good.

Readline saves the old SIGINT signal handler, restores it, and sends another
SIGINT to itself after restoring it.  Any application-specific SIGINT handling
should still take place.

Bash, however, has a hook, in the form of a flag, that different parts of
the code can set to tell the signal handler to interrupt immediately rather
than simply setting a flag.  The code that calls readline uses this to
longjmp back to the top level when readline re-sends the SIGINT to the
shell. 

The problem is that readline assumes that if the signal handler returns,
after it resends the SIGINT and clears the signal mask so it will get
through, it is to go on.  It is the application's responsibility to handle
SIGINT however it likes -- readline should be perfectly happy if you want
to ignore SIGINT when you call it. 

rc just sets the flag and lets readline continue.  Readline reads
until a newline and returns the line.  At that point, rc finally
notices that SIGINT was caught and longjmps back to the top level.

> Furthermore if signal handling in readline is disabled
> the key loses it's meaning as SIGINT!  (This is strictly readlines
> "fault")

It's probably not a good idea to build readline with HANDLE_SIGNALS
undefined.  Readline disables ISIG if it's not defined.  It has to be
able to clean up after itself, and especially to restore the terminal
to a sane state.

Chet

> 
> While I can live with this, it is rather unaesthetic and just plain
> bugs me.  Any clues?
> 
> Tom
> 
> 

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu