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