NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/os/linux/6749

Text File | 1992-07-26 | 3.6 KB | 70 lines

Newsgroups: comp.os.linux
Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!murphy!fortony
From: [e-mail]
Subject: various questions and answers
Message-ID: <fortony.712213298@murphy>
Originator: fortony@murphy
Sender: [e-mail] (Net Noise owner)
Organization: University of Illinois at Urbana
Date: Mon, 27 Jul 1992 05:01:38 GMT
Keywords: weird behavior
Lines: 57

Contents: *more* questions about rc/termcap, and answers about X

Does anyone with some free time have /bin/rc compiled?  I've managed to get
it completely functional, but there seems to be some deviant behavior
it and control characters which I can't figure out.  My .rcrc file
contains "echo blah" "stty erase ^V^H" (the real backspace character, that
is), and "stty", in that order.  When I log in, I see 'blah', a listing
from stty including erase being mapped to ^H, and the prompt.  However,
hitting the ^H key performs a non-destructive backspace at that point.
I type "stty erase [backspace]" by hand, and from then on, everything works
fine.

But then, I start up X, and my xterms start up with rc set up to act like a
login shell, and the stty erase ^V^H in the .rcrc file *works* to create
a destructive backspace.  Which is great, right?  I'll just never leave X --
but now ^C in a program executed under rc (xmartin, for instance) doesn't
kill xmartin *or* rc, but the *xterm* they're executed in.  I guess I don't
get it.  I looked at the termcap file, but everything looks alright.  Does
anyone else have experience with bugs in this area?


I've found that clock.exe is not a useful utility.  It has two main bugs which
are a pain in the modern world:  First, it's case sensitive, which means that
clock et4000 doesn't tell you the right information, while clock ET4000 does.
Secondly, my upper clocks are variable.  This seems to be reasonably common.
The usual environment I would execute clock.exe in is a 24*80 DOS session.  The
usual environment I use in Linux in text mode is 40*100.  Now, the *sneaky*
thing is, the more resolution I demand of Linux's text mode, the *lower*
my clocks go.  So at 24*80, I have a clock which zips along at 88, and at
50*132, that clock is (for some reason) at 11.

So how do you determine clocks?  Well, this worked for me: comment out your
Clocks line in your Xconfig file, forcing X386 to figure it out all by itself.
Then type 'startx 2> /usr/lib/X11/Xclocks'.  It's entirely possible that your
screen will go nuts and you will not get anything close to X.  At this point,
though you don't believe it, you're at your standard Linux prompt, but the
screen will be completely screwed.  Type 'sync' and 'reboot'.  Note that all
of this assumes you're root.  It's possible to do this as not-root, but I
can't think of a standardized world-writable directory, so just follow the
directions above.

X386 prints its clock guesses to stderr.  The above redirects stderr to a file.
Since X386 terminates after finding wrong clocks, the file gets closed just
fine.  However, you want to sync to be sure.  After the reboot, examine the
file you've created (/usr/lib/X11/Xclocks) and copy those clock values into
your Xconfig file.

NOTE: for people with cards like mine, you will want to repeat the above
for EACH OF THE POSSIBLE VALUES OF STARTING SVGA MODE -- INCLUDING NONE
(pressing a key to continue).  I find that I get my best clocks if I do not
press return to see the other modes, but rather go on in 24*80 text mode.

G'luck!

--
a b c d e f g h i j k l m n o p q r s t u v w x y z
Felix Sebastian Ortony    [e-mail]