What does csh require of its tty?

[jc at sppip7.lkg.dec.com]

Well, I'm sure that the folks in comp.unix.programmer will say that
this belongs in comp.unix.shell, and vice-versa, so I'll post it to
both and maybe someone will actually know the answer..

What I'm doing is using a privately-developed comm package that has
control of a bunch of things including serial ports, and starts up
various applications.  Sort of like getty, but with quite a lot more
intelligence, so it knows how to do things like talk to modems, dial
numbers, make terminal-switching network connections, and lots of 
stuff like that.

Sometimes it has to log people in and start up their login shell.
This goes quite smoothly if the shell is sh or ksh.  But if it is
csh (as is most often the case), sometimes it works, and sometimes
csh sits there like a zombie.  Very often the zombie csh processes
are gobbling cpu time, but they don't interact with the terminal.
If I start sh on the same line, it works just fine.

I've determined that, like TFM says somewhere, csh requires the NTTY
line discipline.  It needs some other things, too.  E.g., it won't
work on a raw, non-blocking port (which some other applications like);
it puts out a steady stream of prompts, and treats each byte as a
1-char input line.  This doesn't surprise me.  But it has some other
requirements for its terminal that I can't figure out.

At the moment, I have a login here that used /bin/sh, and that worked
fine.  When I typed a "csh" command on the other end, it produced a
/bin/csh that is using time like crazy (roughly 2/3 of the cpu time)
and it hasn't given a prompt yet.  I can kill it, and the sh again
works.  But no set of options to csh seems to cause it to work.

Does anyone have any idea how to make csh work?  Is this perhaps 
documented somewhere?

This is being done on some Ultrix 3.1 and 4.1 systems, with VAX and
MIPS processors, but the intent is to port it to other systems, so
it likely doesn't matter much what these machines are.  My makeraw()
and makesane() routines already have more #ifdefs than you'd believe,
and a few more wouldn't materially affect anything.

+----------------------------------------------------------------+
Reply-to: John Chambers <jc at sppip7.lkg.dec.com> or <ub40.enet::jc> 
+----------------------------------------------------------------+