rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
* Re: Signal follies with rc and readline
@ 1997-02-23 20:29 Tom Culliton
  0 siblings, 0 replies; 2+ messages in thread
From: Tom Culliton @ 1997-02-23 20:29 UTC (permalink / raw)
  To: culliton, rc

Oh damn!  Spoke to soon I guess, if you longjmp out of catcher for any
signal that GNU readline doesn't catch or SIGWINCH which it mishandles,
then it gets bunged up as well... Sigh...  Back to the drawing board...

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Signal follies with rc and readline
@ 1997-02-23 20:14 Tom Culliton
  0 siblings, 0 replies; 2+ messages in thread
From: Tom Culliton @ 1997-02-23 20:14 UTC (permalink / raw)
  To: rc

I've just spent a couple days deep C diving on the wreckage from the
famous collision of the "unsinkable" rc with the gnu ship readline in
the sea of linux.  This was strictly hard suit stuff, and even though
I've been working at 1 atmosphere, it feels like I've got the bends.

OK, here's the story...  RC wants to catch signals, readline wants to
catch signals, and they don't play nice.  This is made worse by the
fact that RC assumes it's the only bull on the block, and readline (at
least as of rev. 2.0) is broken and inconsistent. 8-P

GNU readline assumes that if you have SIGWINCH you also have Berkley
semantics and doesn't reset the handler after catching the signal.  As
if this wasn't bad enough, it tries to daisy chain to the "old" signal
handler (in this case rc's catcher()), which will do lord only knows
what, without cleaning up the terminal settings.  (Since catcher() was
longjmp'ing out, the terminal was hosed and rc would get EOL on the
next call to readline and puke.  Ignoring the EOF left you hung.) 8-P

As for the rest of the signals that it catches, (SIGINT, SIGALRM
SIGTSTP, SIGTTOU SIGTTIN) unless you treat readline as a "slow" system
call and longjmp out of catcher() they're basically ignored, you
return to the readline signal handler and it goes back into business.
On POSIX systems, such as Solaris and Linux, using sigsetjmp and
siglongjmp helps because readline mucks with signals and signal masks
as well, and these functions save and restore those.  If you do
longjmp out it works OK, because readline cleans up before reraising
the signal.

For now my solution is to: 1) Treat readline as a slow system call,
this includes applying my patch from 93.05.13, which isn't in either
rc-1.5betadev-1 or rc-1.5-linux. (If you use readline you need this
patch!!!) 2) for POSIX machines use sigsetjmp/siglongjmp, and pass
sigsetjmp a non-zero second argument. 3) Until I can publish a patch
to readline or get one from GNU, NOT longjmp on SIGWINCH when using
readline. 8-P

BTW - At least under RH4.1 you MUST link statically when using
readline or trip.rc will hang when using -i to force interactive
echoing from a subprocess. (WTF!?!) Sigh.  I have NO clue on this one,
probably something with a static or global in the readline librbary.


PS - I'm a bit fried out so let me know if this makes any sense. ;-)

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1997-02-23 20:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-02-23 20:29 Signal follies with rc and readline Tom Culliton
  -- strict thread matches above, loose matches on Subject: below --
1997-02-23 20:14 Tom Culliton

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).