From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.clark.net ([168.143.0.10]) by hawkwind.utcs.utoronto.ca with SMTP id <24623>; Sun, 23 Feb 1997 15:16:11 -0500 Received: from explorer2.clark.net (culliton@explorer2.clark.net [168.143.0.5]) by mail.clark.net (8.8.5/8.6.5) with ESMTP id PAA15737 for ; Sun, 23 Feb 1997 15:14:08 -0500 (EST) From: Tom Culliton Received: (from culliton@localhost) by explorer2.clark.net (8.8.5/8.7.1) id PAA28416 for rc@hawkwind.utcs.toronto.edu; Sun, 23 Feb 1997 15:14:10 -0500 (EST) Date: Sun, 23 Feb 1997 15:14:10 -0500 Message-Id: <199702232014.PAA28416@explorer2.clark.net> To: rc@hawkwind.utcs.toronto.edu Subject: Signal follies with rc and readline 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. ;-)