Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!hplabs!hplabsc!daemon
From: daemon@hplabsc.UUCP
Newsgroups: comp.mail.elm
Subject: question - 4bsd ^Z handler interaction with pipes
Message-ID: <2083@hplabsc.HP.COM>
Date: Tue, 23-Jun-87 01:52:51 EDT
Article-I.D.: hplabsc.2083
Posted: Tue Jun 23 01:52:51 1987
Date-Received: Wed, 24-Jun-87 06:36:44 EDT
Sender: daemon@hplabsc.HP.COM
Reply-To: mkhaw@teknowledge-vaxc.ARPA (Michael Khaw)
Organization: Teknowledge, Inc., Palo Alto CA
Lines: 20
Approved: taylor@hplabs (with 'postmail')


I've found that when I display a message in elm and ^Z at the "more" prompt,
I'm hung.  This seems to happen because elm is using a pipe to run the pager
program.  If I use "ps" from another tty to look at the hung login, I see
a parent elm process with garbage in the "ps" "COMMAND" field in device-wait
state, plus a child elm, whose child is a "sh -c more", whose child is the
"more" process that I stopped.  The "sh -c" and "more" process are in stopped
state.

The only way I've found to recover is to kill the "more" and "sh -c" both.

Are there any 4bsd gurus who can explain what a SIGTSTP handler needs to do
to prevent this?  Currently Elm's SIGTSTP handler just restores default
handling (SIG_DFL) and then a kill(0, SIGTSTP).

Mike Khaw
-- 
internet:  mkhaw@teknowledge-vaxc.arpa
usenet:	   {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail:	   Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303