[comp.unix.ultrix] How to do a login shell right on Ultrix

jc@minya.UUCP (John Chambers) (04/10/90)

Well, I've done it on Sys/V and BSD machines, and even on Suns, but 
it's not as easy on Ultrix.  What I have is an application that starts
as a daemon (started by init, mostly, but also from a user's command)
that must grab a serial port, do some fiddling around with it, and
then possibly start up a shell (sh, csh, whatevera) that talks to
the port.  Sorta like telnetd, rshd, or the like, but on a real
/dev/tty* port.  Does anyone know the magic incantations to do it
right?

My suspicions are that I don't understand Ultrix job control, process
groups, and the like.  When I start up a Bourne shell, it mostly seems
to work right, but some funny things go wrong.  For example, passwd
won't run without an id; with an id, it asks for a password, and then
hangs (and isn't kill -9able).  Who shows the correct user on the
port, so I guess I'm getting /etc/utmp correct; it's simpler than
on most Unices.

The csh is puzzling.  It comes up a zombie.  Sometimes it is hung in
an unkillable state; sometimes it sits there gobbling cpu time, but
never says anything to anyone (even with echo commands in .login and
.cshrc).   The manual says that csh requires the "new" tty discipline,
so I did that, but apparently something more is needed.  When I start 
csh as a child of a Bourne sh, it hangs the same way; when I kill the 
sh, the csh also goes away.  Oh, BTW, when csh is started, the original 
daemon process (which is sh's parent and csh's grandparent) gets a SIGCLD 
signal, apparently instantaneously with the csh's startup.

It is truly entertaining to see the variety of undocumented "rules"
that the various vendors have come up with in dealing with the
apparently-simple job of starting up a shell and attaching it to
a controlling terminal.  Does anyone have an example of how to do
it right on Ultrix?  Or perhaps a pointer or two into TFM (other than
obvious places like execv, tty, signal, and so on)?

One of the things that is definitely broken is that /dev/tty doesn't
work right.  I've grepped for it in the manuals, and haven't found any
hint of how one (i.e., getty/login) goes about setting it up.  It seems
to be firmly embedded in a Someone Else's Problem field.  Any ideas?

(Next will come the even more fun task of starting such a shell from
a mouse event within a DECwindows application.  Can you say "proxy
agent?  ;-)

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]

brnstnd@stealth.acf.nyu.edu (04/13/90)

In article <127@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
> What I have is an application that starts
> as a daemon (started by init, mostly, but also from a user's command)
> that must grab a serial port, do some fiddling around with it, and
> then possibly start up a shell (sh, csh, whatevera) that talks to
> the port.  Sorta like telnetd, rshd, or the like, but on a real
> /dev/tty* port.  Does anyone know the magic incantations to do it
> right?

It sounds like you should be using pseudo-terminals. If you pick up my
pty program you can just do, e.g., pty -d /bin/csh (-d meaning it's
detached in the first place, as from a daemon). I'm sending a new 'n'
improved version of pty to comp.sources.unix soon.

---Dan