non-job-control sh (was: Re: System V Release 4.0 Developers)

[Steve Summit]

A while ago, in article <Oct.11.16.08.54.1988.16377 at ron.rutgers.edu>, ron at ron.rutgers.edu (Ron Natalie) wrote:
>If the shell doesn't know about job control, some not so fun things happen
>when processes suspend.  Best demonstration, start up /bin/sh and then run
>a program like talk and type ^Z.  The shell doesn't know about job control
>so it just sits there and waits for the job to exit, which it isn't going
>to do because it's suspended.

In my experience this isn't a problem.  A shell that doesn't know
about job control also certainly doesn't know about process
groups, so it won't put processes it starts up in separate ones.
If an old Bourne shell is started up beneath a job-control shell
such as ksh or csh, and control-Z is typed, the Bourne shell is
suspended as well, along with anything which has been invoked
beneath the Bourne shell (everything being in the same process
group), and control reverts to the parent, job-control shell.  A
"jobs" command there will report that it is the sh command that
has been suspended, because the parent shell can't know what you
had started up beneath the sub-shell.  When you fg it, the shell,
though no longer suspended, is still waiting for its child to
exit, if there is one.  You can also suspend sh's with nothing
running beneath them.

If, on the other hand, your login shell is /bin/sh, so there is
no job-control shell above it, by default you get the old tty
line discipline, so typing control-Z just puts a SUB character on
the input stream (the old tty driver has no suspend character,
so ^Z isn't special).

The only real problem is when you're using an old shell as a
login shell, but you're using the new tty line discipline, with a
suspend character enabled.  As I recall, ^Z then logs you out,
because init regains control when the shell is suspended, and it
is not ready, willing, or able to do job control for you.  (The
fact that you get logged out rather than zombieified may require
some special handling on init's part.)

The previous discussion applies to BSD systems.  Are things
different enough on other systems with job control that
attempting to suspend non-login Bourne shells is a problem?
Seems to me that the easy solutions are either

	1. make sure there's a job-control shell above you
	2. make sure you're using the old line discipline
	3. disable the suspend character

If solutions 2 or 3 are being thwarted by random programs
changing to the new tty driver and/or enabling a suspend
character, that's a problem with those programs.

If you're up to it,

	4. add job control to the Bourne shell

though a noble effort, is nontrivial and requires source, and
anyway it's been done.

(Option 1 may sound strange, but it's what I use on systems where
I can't get the Korn shell.  I start a csh, underneath my login
/bin/sh if necessary, then start another sh beneath csh.  This so
I don't have to interact much with csh which, heretical though it
may sound in these enlightened days, I can't stand.  We Bourne
shell users have been dragged kicking and screaming into job
control even if we didn't think we needed or wanted it, because
when "they" added job control, they started taking our shell
escapes away.  You can't use rlogin effectively if your login
shell is an unmodified /bin/sh, because rlogin has only the
suspend command ~^Z, and not the shell escape ~! which, like cu
before it, rlogin should also have.  This may have been Ron's
problem with talk, which probably doesn't have a shell escape,
although its predecessor, write, did.)

                                            Steve Summit
                                            scs at adam.pika.mit.edu