You are not logged in. Login Now
 0-24   25-48         
 
Author Message
jeffk
Terminal Terminal woes Mark Unseen   Jan 8 05:15 UTC 1993

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.
scg
response 1 of 48: Mark Unseen   Jan 8 23:17 UTC 1993

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?
davel
response 2 of 48: Mark Unseen   Jan 9 02:14 UTC 1993

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.)
tsty
response 3 of 48: Mark Unseen   Jan 10 05:59 UTC 1993

  << is there a substitute character for the  ^  in case  ^  is
not available??>>
remmers
response 4 of 48: Mark Unseen   Jan 11 01:24 UTC 1993

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.
davel
response 5 of 48: Mark Unseen   Jan 11 02:01 UTC 1993

Oops.  Thanks, John.
jeffk
response 6 of 48: Mark Unseen   Jan 11 05:03 UTC 1993

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.  :)
popcorn
response 7 of 48: Mark Unseen   Jan 12 04:27 UTC 1993

This response has been erased.

jeffk
response 8 of 48: Mark Unseen   Jan 12 06:09 UTC 1993

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.  :)
rcurl
response 9 of 48: Mark Unseen   Aug 26 16:22 UTC 1993

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? 
aa8ij
response 10 of 48: Mark Unseen   Aug 26 18:29 UTC 1993

    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. ;)
davel
response 11 of 48: Mark Unseen   Aug 26 21:15 UTC 1993

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.
danr
response 12 of 48: Mark Unseen   Aug 26 23:39 UTC 1993

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.
rcurl
response 13 of 48: Mark Unseen   Aug 27 03:37 UTC 1993

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.
davel
response 14 of 48: Mark Unseen   Aug 27 09:41 UTC 1993

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.
popcorn
response 15 of 48: Mark Unseen   Aug 27 11:54 UTC 1993

This response has been erased.

mju
response 16 of 48: Mark Unseen   Aug 28 10:24 UTC 1993

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.
kentn
response 17 of 48: Mark Unseen   Nov 2 22:26 UTC 1993

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)?  
davel
response 18 of 48: Mark Unseen   Nov 3 01:26 UTC 1993

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.)
remmers
response 19 of 48: Mark Unseen   Nov 3 01:58 UTC 1993

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.
kentn
response 20 of 48: Mark Unseen   Nov 3 02:16 UTC 1993

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.
davel
response 21 of 48: Mark Unseen   Nov 3 10:55 UTC 1993

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.

remmers
response 22 of 48: Mark Unseen   Nov 3 13:19 UTC 1993

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.
kentn
response 23 of 48: Mark Unseen   Nov 3 19:11 UTC 1993

I guess I was trying to automate things too much.  I wouldn't want
to add to Grex's overhead.  
mju
response 24 of 48: Mark Unseen   Nov 4 06:06 UTC 1993

It is quite possibly a bug in vi, and may be fixed when we upgrade
to SunOS 4.x with the SUn-3.
 0-24   25-48         
Response Not Possible: You are Not Logged In
 

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