rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Tom Culliton <culliton@clark.net>
To: rc@hawkwind.utcs.toronto.edu
Subject: Signal follies with rc and readline
Date: Sun, 23 Feb 1997 15:14:10 -0500	[thread overview]
Message-ID: <199702232014.PAA28416@explorer2.clark.net> (raw)

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.

Tom

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


             reply	other threads:[~1997-02-23 20:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-02-23 20:14 Tom Culliton [this message]
1997-02-23 20:55 ` solaris Scott Schwartz
1997-02-23 20:29 Signal follies with rc and readline Tom Culliton

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=199702232014.PAA28416@explorer2.clark.net \
    --to=culliton@clark.net \
    --cc=rc@hawkwind.utcs.toronto.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).