rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Chet Ramey <chet@odin.INS.CWRU.Edu>
To: culliton@srg.af.mil
Cc: rc@archone.tamu.edu, chet@odin.INS.CWRU.Edu
Subject: Re: rc and readline and SIGINT
Date: Tue, 21 Apr 1992 13:36:44 -0500	[thread overview]
Message-ID: <9204211836.AA11917.SM@odin.INS.CWRU.Edu> (raw)
In-Reply-To: Message from culliton@srg.af.mil of Fri, 17 Apr 1992 16:52:51 -0500

> 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


             reply	other threads:[~1992-04-21 23:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-04-21 18:36 Chet Ramey [this message]
  -- strict thread matches above, loose matches on Subject: below --
1992-04-24 21:46 Tom Culliton x2278
1992-04-17 21:52 Tom Culliton x2278

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9204211836.AA11917.SM@odin.INS.CWRU.Edu \
    --to=chet@odin.ins.cwru.edu \
    --cc=chet@po.CWRU.Edu \
    --cc=culliton@srg.af.mil \
    --cc=rc@archone.tamu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).