rc and readline and SIGINT

rc and readline and SIGINT

[Tom Culliton x2278]

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.

Under rc-1.2 with or without readline if I hit the key for SIGINT it
aborted the current input line.  This was good and righteous and all that.

Under rc-1.3 with readline it no longer seemed to work right.  Since
1.3 had signal handling (and other) problems it was hard to be sure
what the trouble was.

Under rc-1.4beta without readline SIGINT works as expected/desired and
aborts the line.  With readline the line doesn't get executed, but it
doesn't get cleared or quit either and further input is accepted but
not executed.  Furthermore if signal handling in readline is disabled
the key loses it's meaning as SIGINT!  (This is strictly readlines
"fault")

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

Tom

Re: rc and readline and SIGINT

[Tom Culliton x2278]

Well this is the first chance I've had to really take a good look at
what Chet had to say on the topic and relate it to the the rc code. 
From looking at signal.c, util.c, and wait.c it looks like the problem
would be easily solved by treating readline as a "slow" system call. 
Before I plunge into this, can anybody think of reasons that this would
be a bad idea?  Byron?

Tom

Re: rc and readline and SIGINT

[Chet Ramey]

> 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