Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!gem.mps.ohio-state.edu!sunybcs!marvin.cs.Buffalo.EDU!ugkamins From: ugkamins@marvin.cs.Buffalo.EDU (Dr. R. Chandra) Newsgroups: gnu.emacs Subject: Emacs under INTERACTIVE Message-ID: <13980@eerie.acsu.Buffalo.EDU> Date: 30 Nov 89 08:21:32 GMT Sender: news@acsu.buffalo.edu Reply-To: ugkamins@marvin.cs.buffalo.edu (Dr. R. Chandra) Organization: SUNY @ Buffalo Lines: 46 Well, I got and applied the diffs for 18.54 - 18.55, but to no avail. The editor still refuses to keep the shell around (forced logout). The terminal still gets set to a fixed 1200bps. I have had a few replies, and most of those dealt with the "messed up" termcap entry. To summarize the "RD" problem's solution for the net, get at the text file for at386 (use infocmp to generate if necessary), remove the xt entry from AT386, then compile (tic) that modified file as superuser, optionally changing the name (like at386-gnu or something). Perhaps a little more information would tell you something. We have NOT installed: X, TCP/IP, STREAMS. We have no room for them and even less use. People tell me (in email) that things seem to compile best when all this stuff compiled in, and compiled into the kernel. HAVE_X, HAVE_PTYS and stuff like that is either commented out or #undef'd. The system is (I'm pretty sure) Sys V Rel 3 with a version (?) number of 2.0.2, on a '386 IBM PC AT-type machine, so I am using s-usg5-3.h and m-intel386.h. Something tells me that an errant modification of the terminal control structure (tchars, sgtty buffer, or something like that) followed by an ioctl is responsible for the fixed 1200bps speed. Similarly, stty 0 is supposed to simulate a hangup, so when this corrupt data is undone to exit back to the shell (go back to normal cooked terminal mode instead of character at a time, among other things) with another ioctl, that call is probably similarly done incorrectly somehow. The only other thing I can think of is "overzealous :^)" use of kill() somewhere within a loop of some kind, and accidentally kills the shell too. My shell is csh, and I see "% logout" then garbage if I'm on a modem, or just a LF (no CR) if I am on the local console. I also would like to stress that the serial port driver is never asked to hang up the line, as in a normal logout (drop DTR I think). On the consoles (console and virtual terminals too), the usual getty banner appears almost right away, and on the modem, the uugetty does the normal login: sequence, but without hanging up first! Anyone having any (more) insights, or a working INTERACTIVE configuration, please mail me. --- Where do we keep our bison and yacc? In a zoo of course! "Answer my question, tell me no lies. Is this the real real world, or a fool's paradise?" -- Eric Woolfson & Alan Parsons (Lately, I'm beginning to believe the truth is the second case.) ugkamins@sunybcs.UUCP (UnderGraduate john i. KAMINSki) Brought to you by Super Global Mega Corp .com