ugkamins@marvin.cs.Buffalo.EDU (Dr. R. Chandra) (11/14/89)
I would like to know of anyone who got GNU Emacs to run properly under 386/ix (INTERACTIVE UNIX System V Release 3). I have the 18.54 revision distribution. Here are some of the problems I've encountered: logs out shell (C shell) on C-x C-c (requires logging in again) will NOT rebind DEL ( "\C-?" "\177" "\377" ) to the same as C-d needs to comment out the section on determining "window size" (terminal size) in order to get it to compile. Since everyone who uses the system will be using 24X79 terminals, I substituted width and height to those constants. Anybody else having these problems?
ugkamins@marvin.cs.Buffalo.EDU (Dr. R. Chandra) (11/15/89)
More bad news. I tried logging into our UNIX box from home after having the problems at work. Additionally, when calling in at 2400 bps, Emacs mysteriously seems to change the speed to 1200 bps after invoking the editor, because I get more slowly appearing garbage on the screen, and when I switch down to 1200 bps, I get part of the status line clearly but the rest is garbage. This doesn't happen on the local consoles (probably because their speeds are not changeable, eh? Rather difficult to change the speed of video RAM, eh?). Also, I notice an "RD" at the very beginning of the status line where the version here on marvin just has "--". Is this normal? marvin's version is 18.53. I think this must be some sort of misused escape sequence, like when I invoke vi with vt100 as my terminal on the consoles, when it is supposed to be AT386 (when I exit, I get extraneous characters before my shell prompt). Again, any help would be appreciated.
fischer@utower.UUCP (Axel Fischer) (11/20/89)
In article <13264@eerie.acsu.Buffalo.EDU> ugkamins@marvin.cs.buffalo.edu (Dr. R. Chandra) writes:
->Also, I notice an "RD" at the very beginning of the status line where
->the version here on marvin just has "--". Is this normal? marvin's
->version is 18.53. I think this must be some sort of misused escape
->sequence, like when I invoke vi with vt100 as my terminal on the
->consoles, when it is supposed to be AT386 (when I exit, I get
->extraneous characters before my shell prompt).
Yes - you are right.
You have to fixup your terminfo-entry for the AT386.
I've had the same problem - but I have taken a terminfo entry for
ANSI from a friend, modified it and now all runs well.
At my side this has happend also on the system console (RD in status line ..)
Hope this helps,
Axel
--
UUCP : ...!uunet!unido!tmpmbx!utower!fischer
Telex: 186672 net d
The man in black fled across the desert,
and the gunslinger followed ...ugkamins@marvin.cs.Buffalo.EDU (Dr. R. Chandra) (11/30/89)
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)