I am running Linux at home right now and it supports 100 character lines
and 43 lines per screen.  I'm using a VT100 emulation.

How does one tell Grex not to reset my terminal to 80x25?  In my case, this
process also screws up my local terminal setting as well.  I've played with
the stty commands:  stty rows 43   and stty cols 100.  Neither do diddly.

My other question pertains to the erase key.  Is erase different in vi than
in the command line?  my backspace key works find on the command line but
screws up royal in vi.  Is there a setting for .exrc that I should be using
in addition to the stty erase "{key}"?  Getting  ^?  every time I press
backspace is VERY annoying.

Thanks...in advance.

48 responses total.

My backspace key used to work as back-space.  Now, all I get when I push it is
a ^H.  The Delete key works, but is not in the world's most convenient place.
Is there a way to fix this?

Try the following at a shell prompt:
stty erase '^H'
(the ^H in this case you type as two characters, BTW).  If this does the
trick, you need such a command in whatever it is that csh uses when you
log in (.login, I think).
Or possibly the place is .cshrc; I'm no csh expert.  Someone who is
might want to take the time to explain the difference.
(I conjecture that you changed your login shell from sh to csh, and that
this change was first noticed after that.)

  << is there a substitute character for the  ^  in case  ^  is
not available??>>

Actually, you can use an actual control-H in the "stty erase"
command.  It doesn't have to be two characters, although it can
be.

Oops.  Thanks, John.

The ^? worked marvvy for me and Linux.  Thankx.

BTW:  Now I have Linux replacements for all of my DOS programs, except,
possibly, Ami Pro.  I don't have quite the memory to run X, nor the
processing muscle to run Doc from within X.  I'll just do it on my wife's
Mac or keep Ami Pro around in Dos.  Everything else works fine.  Sometimes
a little cruder, but nevertheless, it works!

Bye, Mush-DOS.  :)

This response has been erased.

Ami Pro is a word processor for MS-Windows.  It is excruiatingly easy to
use and understand.  It has the status of being the first Windows word
processor, running in version 1.1 of Windows back in 1985.  Samna was
acquired by Lotus in 1989 or 1990 and Ami Pro sales have never been better.

I use it after trying MS-Word4Windows and WP4Windows.  Word is too
detail-oriented and WordPerfect is, well, WordPerfect.  (I *hate* WP,
espectically those !@##%^& REVEAL CODES).

Anyhow, its the only major peice of software that I've bought, other than a
communications program.  I'm a shareware nut, but nothing comes close to
AmiPro.  Check out a PC/DOS magazine for an ad sometime.  I'm sure it'll be
in there.

I think its better than anything on the Macintosh, as well.  Easy,
intuitive and straight-forward.  And no, I don't work for Lotus.  :)

This is a sort-of related item for this question: we sometimes pick up
the phone while another is using the modem, which scrambles the
connection. (Here I sit connected to Grex, and my daughter asks, "May
I use the phone.", and without thinking I say "sure"...blooey.)
Anyway, I would like to know *precisely what is happening* that creates
the nonsense string that results. For example, here is a partial copy of
one such:

                         
                          x49?t5JU;:<457{oW'u|PZ&zq(^t*CVM4i2_G6V'^y4wkfz9;2*{YQ
                          
>OKgi_G:X0n3wnm52WO;v_{;?y}a}5
PEi#9m>NQrKW\ZY=}k{Q7f{^]       t<'7mY1/L9u*WI[,'_TmA  
QS_?{v3W^TaC*^nW=y4(^w^5 \ZfjQ2cjzyho^Jz4B9Qwh
                     xLi=AKR$77u{WzOLg{1 

What is the noise signal source that superimposes itself upon the data/
handshake stream, and exactly how does it corrupt it to produce the above?
In principle, the *message* is still in that stream, and could theoretically
be extracted, couldn't it? 

    There is no "message" per se, Rane. But noise like a pop or something 
causes the modem to produce a random character. Mod dem  The noise is
being modulated into randon characters. 
    I would guess that your (and mine) computer makes little noises that 
tell the modem what to reproduce on Grex, when a stray noise gets in there
it confuses the modem and the modem reponds by generating randon letters.

    The noise is made by air rushing past the open speaker of the extension
phone, when someone picks it up. Sometimes it can log you right off.

Hopefully that will explain it. I know very little about the nuts and
bolts of modems. I just know how to plug them in. ;)

I don't really know anything about the analog part of the link, either.  But
in the digital serial communications part, the characters are being sent
(of course!) serially - one bit at a time, in packets with data bits &
(if I recall correctly) a special start bit of some kind and one or two
stop bits which I think are just like data bits (but I may be wrong).  (That's
the "1" of "N81" - the "8" is the # of data bits.)  There's also an optional
parity bit, which will be there if parity is not "none".

I *presume* that 1 and 0 are getting systematically translated into certain
tones, or something along those lines.  At any rate, the noise on the line
can break up the signal in all kinds of nasty ways.  If it were just generating
characters, you would get mad but it wouldn't normally hang you up.  But at
some point the garbage confuses the modem so much it thinks it's no longer
getting *data*, & it will hang up on you.

This is all pretty much correct.  A 300 baud modem is simple frequency
shift keying.  One tone equals a mark, another equals a space.  For the
higher baud rates, they also do some phase shifting.  Noise bursts
superimpose on the normal signal, and while the receiving modem does
its best to filter it out, at times the noise shifts the tone and/or
phase enough to obscure the signal.

This is surprising, as the "rushing" noise on the line, which is a composite
of all those marks and spaces, is *much* louder than the sound that can be
picked up from the receiver being off hook. I would expect noise
interspersed with sense - not total gibberish.

Well, again - you're not somehow adding a few garbage characters, you're
adding random bits to the stream of characters.  It doesn't take all
that much.  In fact, I believe that (on the digital level) the start bits
are distinguishable from other bits, but I don't know how this works on
the analog part; if you add one bit you may do something like shifting
the whole stream of packets by one bit until some resynch occurs.  That
could produce a **lot** of garbage.

This response has been erased.

One would assume that, since Grex is using even parity, it would
simply discard any character whose parity bit wasn't correct.
Unfortunately this isn't true; since parity is not a very good
form of error-checking, most systems simply ignore parity errors.

Here's another stty question, I think.  I dial in to grex from a
number of different computers with varying numbers of screen rows.
So, I've been typing 'stty rows X' where X is correct for the
machine I'm using.  Now...what I'd like to do is get 'more' to use
whatever number of rows I've defined with stty.  Is it supposed
to do that (because it doesn't appear to be)?  If not, is there
some way I could write a short alias or script to set more's rows
automatically (as in is there a variable that holds the number
of rows)?  

If # is the number of lines you want it to scroll, then setting the
environment variable MORE to -# (plus any other options you want to
specify) will cause that value to be used.  more uses your termcap
setting by default (# rows - 2).  So, for example, if you want it
to scroll 20 lines and are using sh, you would use
MORE='-20';export MORE
in your .profile.  (Those who use csh should know how to modify this
for that purpose.  Sorry, I may but I'm not sure.)  Or since you want 
to be able to set it conditionally, either put something in your
.profile or .login to ask you or else set it externally by hand.

(The quotes are like that in the man page, but aren't necessary unless
you have more than one default option you want to set up; in that case,
enclose the entire set in quotes.)

Hmm.  The "stty rows #" method is supposed to work too.  It does for me.
Dunno why it doesn't for you, Kent.

In fact, every program that cares about screen size *should* interrogate
the stty "rows" and "cols" settings and adjust its behavior accordingly.
The only program on grex that I've found doesn't do this is vi, which is
unfortunate since vi is one of my most heavily used programs, and I use
terminals of varying sizes too.  To get vi to change its concept of the
number of screen rows, I have to switch to a termcap that specifies the
right number of rows.  (That's why I installed all those termcaps like
vt102-39, vt102-49, etc. that differ from one another only in the number
of rows that are specified to be on the screen.  Wouldn't be necessary
if all programs were well-behaved.)  The other editors I've tried --
emacs, pico, jove -- all respond to "stty rows #" correctly.

Well at work, vi does interpret stty rows correctly, as does more,
so I've not had this problem there.  I'm not sure what the difference
is.  Is there a variable which contains the rows setting?  Then
I could alias 'more' to 'more -rows' and never have to worry about it,
except as I said, setting stty when I login.

stty doesn't set any variables up automatically.  You could easily write
an awk script that does stty all, scans for /[0-9]+ rows/, and extracts
the setting.  That's a lot of overhead to have every time more executes,
so I think you'd want to run it when you set your rows, instead - in
which case just setting MORE & exporting it would be about as easy,
wouldn't it?

Why not set up your .login to prompt you & set both, & be done with it?

I have no idea why setting the stty rows works for remmers; according to
the man, more uses termcap, not stty.  To quote:

     More looks in the file /etc/termcap  to  determine  terminal
     characteristics,  and  to determine the default window size.
     On a terminal capable of displaying 24  lines,  the  default
     window size is 22 lines.

Probably a case of software being out of sync with documentation.

What programs like 'more' are supposed to do, on systems whose stty
supports the 'rows' and 'cols' options, is to use the stty settings
if they're non-zero, otherwise use termcap.  Vi does this correctly
on some other systems I use, but seems to be stupid about it on
grex.

I guess I was trying to automate things too much.  I wouldn't want
to add to Grex's overhead.  

It is quite possibly a bug in vi, and may be fixed when we upgrade
to SunOS 4.x with the SUn-3.

That's what I'm hoping.

Here is the solution I use; I found the section of /etc/termcap that
applies to my various terminals. I clipped each of those sections into
a file in my home directory. Then I modified my .login file to 
look into MY home director for termcap information! AHA! quicker logins
and the ability adjust that file for whatever I wish, and I have modified
both the #cols and #lines integer.
 The line in .login says :   setenv TERMCAP /h1b/u/tsty/tern  
  
The file    tern   has all the varieties of termcap that I use. 
 And then in my .cshrc file, I have aliases coded for the "name" of the
termcap entries. One happens to be    alias    ter  setenv TERM ti    and
the code   ti    applies to oneof the identifiers on the FIRST line of
one of the termcap entries, its "name."
  
Works Great, Less Hassle

That faster login claim sounds worth checking out.

This response has been erased.

Make that *when* /u is no longer /h1b/u - Marc has announced (somewhere)
the imminent demise of some such things.  I think including h1b, to be
specific.

or even ~tsty/tern

Hmmm, found this out the hard way tonight, as a matter of fact. For
some reason I really prefer to hardcode the paths when it's for
my personal stuff. Hardcodes are now changed.

Got a new set of "stuffs" for vi and the mac. Now comes the
problem - can't get it to be read on login.
  
A while back, somewehre else, the suggestion was made to 
insert into my .login, the lines:
  
        tset $TERM      and
        source ~/setterm
 
fwiw, above those lines is:
  
        setenv TERMCAP /home/tsty/tern
  
((srw, you can't put a ~ character first in the TERMCAP line
if you want it to work right, gots to be either a  /  or the
whole darn termcap entry))
 
I've tried a few adjustments but the grex-box will NOT use
my, in-home-directory termcap entry! Elsewhere, (other boxes)
it's great, here, it's ignored.
 
I read the man pages, and even tried a manual
 
        /home/tsty% setenv TERM vtmac
  
which also fails (the label   vtmac   is correct).
  
Now what?

"setenv TERMCAP ~tsty/term" should work just as well as
"setenv TERMCAP /home/tsty/tern" -- the shell expands the ~
character to the full pathname for your home directory, starting
with a /.

There are a few applications on grex that use the "terminfo" database
instead of termcap.  This includes vi and lynx, and possibly some other
things.  So setting TERMCAP will not enable those applications to find
your terminal description.  I suspect that this is what you're running
into.  To get a custom terminal description to work with everything,
you need to set up a terminfo description (different format) as well as
a termcap description.  It's possible to do this, but I haven't done it
much and would have to review the details of how it's done.  They can be
dug out of the man pages.

Hmmm, remmers' second graph describes two problem's worth of
solution - terminfo (I have a listing for that as well).
  
About the first graph, though,    man termcap  produces, in part,
  
  It
     will look in the environment for  a  TERMCAP  variable.   If
     found,  and  the  value does not begin with a slash, and the
     terminal type name is the same  as  the  environment  string
     TERM,  the  TERMCAP  string  is  used instead of reading the
     termcap file.  If it does begin with a slash, the string  is
     used  as  a  path  name  rather than /etc/termcap.  This can
     speed up entry into programs that call tgetent .....
  
The only question TERMCAP seems to care about is whether
or not the it "begin(s) with a slash," which would +tend+ to
indicate that the ~ first, not being a slash, would be unrecognized.
  
If the shell is going to expand the ~, the man entry should say so,
methinks.
  

This response has been erased.

Ibeleive that TERMINFO needs to be compiled, or someting like
that.  I have the code for TERMINFO (as well as TERMCAP) and
would like to know what, specifically to do with it. TERMCAP
i can deal with. 
 
Sure didn't consider that some terminal useages would rely
on termcap, and others would rely on terminfo. Is there some
particular advantage for switching between the two, aside for
the desired result of having me ask a question ....<g>.

The dual nature of terminal databases on Grex has been brought up
before, perhaps several times in the last year.  At one point, the
two (terminfo and termcap) weren't in sync, but I think remmers got
that fixed.  My understanding of terminfo is that there is a compiler
program that creates/compiles the terminfo database file that is
used by terminfo (i.e., you run a text-coded version of the terminfo
terminal definitions through a terminfo compiler).

This response has been erased.

Re #37:  That's correct, terminfo descriptions are compiled from text
form by a special program.  I brought the two databases into sync a few
months ago, at least for the "common" terminal types (vt52, vt100,
vt102, vt220, etc.).

It's a royal pain that we have to worry about keeping two terminal
description databases in sync.  We don't really have a choice about
that.  The vi editor uses terminfo and we don't have the source, so we
can't change it.  Practically everything else uses termcap.

I'm not sure that terminfo is significantly faster than termcap
overall.  The startup time for programs that use terminfo is faster on
the average than termcap-based programs, *if* the program has to look
up the termcap description in the large /etc/termcap file.  This is
because the termcap file has to be searched linearly for the approprite
description, whereas the terminfo descriptions are arranged
hierarchically in a directory structure, with each terminal having a
separate file.  However, if the termcap description has been stored in
the TERMCAP environment variable, this advantage for terminfo
disappears.

I don't think that once the description is loaded, that terminfo is any
faster than termcap.  I'm not sure how the fact that terminfo
descriptions are compiled impacts speed.

Terminfo can describe more capabilities than termcap.  I believe that
there are standard ways to describe how to display different colors,
for example.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss