Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!think.com!paperboy!hsdndev!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.questions
Subject: Re: how to suspend a process
Message-ID: <10269:Feb1821:14:1591@kramden.acf.nyu.edu>
Date: 18 Feb 91 21:14:15 GMT
References: <7016@alpha.cam.nist.gov> <121503@uunet.UU.NET> <9999@dog.ee.lbl.gov>
Organization: IR
Lines: 32

In article <9999@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
  [ summary of one way to handle TSTP ]

Yeah. It's actually sort of funny watching programs which don't know how
to deal with this: give rn some ^Zs and bgs and it goes into never-never
land. Start it in the background and you're in really deep trouble.

But this begs the question of why the default signal handler operations
aren't available as atomic syscalls in the first place. stop(), tstp(),
ttin(), ttou(), and abrt() (preferably with a filename) are trivial to
add to the kernel, would eliminate the need for several signal-handling
kludges, and would make any character-mode program a lot cleaner.

> If the reason you are catching signals is that you modify a tty state
> (e.g., use CBREAK/not-ICANON mode), you should be careful to pick up
> the new state after the stop.

This is a matter of opinion. Some people believe that the shell should
handle all tty mode changes, including restoring modes after a stop or
termination. Then the shell alone can decide whether to pick up the new
state or not. This too would make the system a lot cleaner: programmers
would not have to repeat the same tty mode munging and signal handling
code in every application. Writing a no-echo, character-mode program
wouldn't require ioctl() or signal() or anything else.

(Of course, the programmer could just run pty -pEc foo to run foo under
a no-echo, character-mode pseudo-tty. Since pty groks job control, foo
doesn't need to handle signals either. But I won't pretend that this is
the right solution. It should not require an extra program and tty just
to do something that the shell should do automatically.)

---Dan