Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.mail.uucp
Subject: Re: Bidirectional Modem Lines under SunOS 4.0.1
Message-ID: <3937@ficc.uu.net>
Date: 21 Apr 89 13:21:10 GMT
References: <160@osc.COM> <743@key.COM> <2209@laidbak.UUCP> <3834@ficc.uu.net> <11549@s.ms.uky.edu>
Organization: Xenix Support
Lines: 39

In article <11549@s.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
> In article <3914@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
> >Why does the shell's parent have to be xterm to satisfy this requirement?

> As I described before -- xterm's job (and that of rlogind as well) is
> to handle the characters going in and out of the terminal session.

Yes.

> The xterm & rlogind processes are conventionally the parent of the
> shell because they take on the task of crafting up the environment
> surrounding the pty.

Conventionally. But they don't have to be... in fact they don't even have
to be related: they could be spawned by parents that know the names of the
virtual devices. But even if they are related it doesn't have to be parent-
child.

> Also they need to know when the child exits so that they can clean
> up after themselves.  This is most easily done if they are the partent
> of the shell so that they receive SIGCHILD (SIGCLD) and/or SIGHUP
> signals.

They can also get SIGPIPEs when the child goes away.

> But right now I can't think of a good reason why it *MUST* be the
> way it is now.  I can envision that init could treat the pty's as
> any other terminal device...

> But then we wouldn't be able to just use a pty without having to
> log in.

Why not? INIT isn't magic... any program could set up the two procs and
kick them off, just as they do with pipes now.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.