How do I get Grex to keep my terminal at 132x43?  It starts out that way, but
digresses to 80x25.  I have a TERMCAP environment line and has those
settings in it, but it doesn't seem to have an effect.  stty line=43
doesn't work either.

Hints, clues, fixes?

33 responses total.

talk to remmers.... he'll concoct some sort of termcap for you.

No, a simple change to his existing termcap will do it.  In the
"setenv TERMCAP ..." line in your .login file, change the string
"\E[1;24r" to "\E[1;43r" in the "is" capability.

The "is" capability is the terminal initialization string, and
the "\E[m;nr" sets the scrolling region on the screen.

I notice also that your TERMCAP line specifies the # of columns as 80.
You probably want to change that to 132.

Thanks!

I'm having a problem with my terminal getting resized and wonder if a
similar solution to that presented in this item previously is a
suitable fix.  Here's my situation:
  I have 'stty rows 24' in my .tcshrc, so that gets set when I
login.  This is usually a good default since I login from several
machines and 24 rows is a common denominator.  Tonight I have the
advantage of a vga monitor and 50 rows.  I forgot to set 'stty rows
49' after I logged in, so the 24 row setting should have been in
effect.  This doesn't normally harm anything since PicoSpan just
scrolls along and uses all 49 or 50 rows.  I entered a response and
tried to edit it with vi.  It was at this point my troubles began.
  When I finished editing and left vi, my terminal was set to one
row at the bottom of the screen.
  I've been able to duplicate this situation and the steps are:
  1. set 'stty rows 24'
  2. run vi, and quit.  This leaves me with half a screen (the 24
    row setting from stty, I suppose).
  3. set 'stty rows 49' in an attempt to get the whole screen back.
  4. run vi, and quit. This leaves me with one line at the bottom.
  5. set 'stty rows 49'  This leaves me with 24 rows at the top,
   and applications (like more) think I have 49 rows so things scroll
   off the top of the screen.
  6. set 'stty rows 24' to get some kind of normalcy.
  7. repeat starting at 2 and end up with one line...etc.

On other machines I've used 'resize' to get back the full screen.
While there is a man page here on Grex for 'resize' I can't find
the program itself.
 
Are there any other solutions I can try?

I'll bet that your problem is that your stty command is in .tcshrc .
This file is sourced by every new subshell that gets started.
Since the action of stty is somewhat global (not local to the shell)
this is a bad place to put that command.

Try moving the stty rows 24 to your .login file.
.login is sourced after .tcshrc, but only for your login shell - not
for subshells.
This will probably prevent the unexpected resizing.
You see, shells are started all the time while you aren't watching.

Sounds very likely.  I'll make the change and see what happens.  Thanks.

This response has been erased.

WEll, sort of.  Now I'm stuck with 24 lines at the top of my 50 line
screen. No more 1 line at the bottom, but no 49 lines either.  

Kent:  There's a file called in my home directory that you might
find helpful.  Try copying ~remmers/vt to your home directory,
making the obvious changes for your setup, and putting the command
"source vt" at the end of your .login file.  It should give you
your full 49 lines.

This response has been erased.

This response has been erased.

You may need the vt320 terminfo, I think - I'm not sure.
And there doesn't seem to be one - here are the vt terminals listed in
/usr/share/lib/terminfo/v:
vt-102          vt-61           vt100           vt100-am
vt100-bot-s     vt100-nam       vt100-nam-w     vt100-nav
vt100-nav-w     vt100-np        vt100-s         vt100-s-bot
vt100-s-top     vt100-top-s     vt100-w         vt100-w-am
vt100-w-nam     vt100-w-nav     vt100am         vt100nam
vt100s          vt100w          vt102           vt125
vt125-am        vt125-nam       vt132           vt200
vt200-js        vt200-ss        vt200-w         vt200-wj
vt200-ws        vt220           vt220-js        vt220-ss
vt220-w         vt220-wj        vt220-ws        vt50
vt50h           vt52            vt61            vt61.5

Someone was going to look into converting the termcap entries from the old
system into terminfo entries.

This response has been erased.

I asked about this in an item I entered (vt220/vt320 confusion, I
think).  You should be able to get by with vt220, but I was unable to
do that either (it had something to do with termcap vs terminfo;
vt220 is in one and vt320 is in the other and some applications appear
to look in termcap, others in terminfo, hence no matter which you set
on the Grex side--vt220 or vt320--you run into confusion). 
  I was using Kermit-DOS 3.13 when I ran into this problem.  Up to
now, when I use Kermit I set it at vt220 and set Grex at vt100.  That
works, but I'm not getting whatever enhancements that vt220 or vt320
offer.  (This is not related to my current resizing woes as far as I
kno).

The problem, as was noted in some other item in this conference,
is that the version of vi running here uses the terminfo database,
whereas everything else uses termcap.  There's a vt320 description
in the termcap file here (I think I wrote it, a few years ago) but
no terminfo vt320 description.

I am the person who volunteered to bring the terminfo database here 
into symc with termcap, but as yet I haven't gotten a round tuit.
I'll have to educate myself a bit first as to how terminfo works,
as I've had no prior experience with that.

As a stopgap measure for vtN users with N >= 200, I think I'll 
put a vt200 description in the termcap file.  Since the terminfo
database also contains one, that will allow folks to use vt200
as their TERM variable and have it work for everything.  If it
doesn't show up within a couple of days, feel free to remind me.
If your comm. software is (accurately) emulating vtN for any
N >= 200, you should be able to use vt200 as your TERM variable
on Grex.

One caveat -- I'm not sure if there's much software on Grex that
actually takes advantage of the VT200 features that aren't already
in VT102, so I don't know that using vt200 will gain you much.
I think I've noticed in the past that GNU Emacs does use some of
the fast screen updating capability of the vt200 and vt300 series.

Valerie is correct that vi here doesn't take advantage of vt102
insert mode.  However, every other  vi I've used on every other
system *does* take advantage of it, so I suspect it's a deficiency
in the terminfo vt102 description -- if so, it's fixable.

At this point, let me as more explicityly: Is there a 'resize'
command to be found on Grex?  If not, can we get one installed?
Thanks.

I believe "resize" only works for xterms, since it uses xterm-specific
escape codes.

(Kent:  Did you try my "vt" suggestion?)

Okay, I lifted the the "vt200" description from the stock Sun termcap
file and put it in our termcap file.  This should allow you to use
"vt200" as your terminal type if you're emulating a VTn for any n>=200.
Let me know if there are any problems with it.

Did a little reading about terminfo and had a look at the vt102
terminfo description.  I was correct -- there's no "insert mode"
capability listed, so vi does character insert the "slow" way.
Should do it faster if you emulate a vt200.

This response has been erased.

I've just been using whatever I started with, so haven't been following
this issue. I think I declare my terminal type to be vt100, but at the
top of this screen it says "DEC VT220". Could I set anything up
different that would cause any noticeable different (improvement, please!)
in what I observe? Re "insert mode": I use pico/pine, and insert appears
to be simple and direct, as far as I can see, even though I think I'm
using vt100 emulation. Am I missing some problem?

Re 18: Yes, it is xterm-related.  Found that out last night after doing
some poking around on the internet and on the machine at work.  I've
been using the 'resize' command right along, even though I don't use
xterm, and it appears to do what I expect it to do (resize my terminal
to the current stty rows and columns settings.
  Re 19: Not sure which vt suggestion you're referring to (there've
been too many vt-whatnots tossed around lately ;).  I did move my
stty commands to my .login (from my .tcshrc), but am currently sticking
with vt100.  My problem is that I use terminals that variously support
24 or 49 lines, and vt100, vt102, vt220, and vt320.  vt100 is the safest
"common denomintor".  Would I gain anything by setting vt200 on Grex and
emulating vt100 on my home computer?  I suspect that would mess my
screen up when vt200 codes got shoved through the vt100 emulation.
  I've forgotten how to output termcap definitions...but it seems to
me I could put such a definition in a file and alter the number of columns
(make a custom termcap definition that I could invoke when I wanted
49 rows).

My "vt suggestion" is in response #10.  Try it, you'll like it!

The should be no need to alter the number of rows and columns in
a termcap description now that Grex is on the Sun-3. The
"stty rows m cols n" command overrides whatever the termcap says.

Ahhhh....thanks.  Didn't look back quite far enough...

Yup, that "vt" script works fine.  I edited it to use the vt200
termcap and for 49 rows.  I'm using pine and vi and picospan all
full screen now (from Kermit using vt220).  Thanx.

Now I have a different interesting phenomenon.  Everytime I read an
item with enough responses to kick in the "more" pager, my screen is
toggled between inverse and normal text.  Any ideas how to get around
this problem?

Sounds like a terminal emulation problem to me.  What kind of
emulation are you using, and which termcap?

Heh, I'll bet it's because I've got vt200 set and am emulating vt102...
gee this is kinda neat, ya oughta try it...heh.  I'll set it back to
vt102 on both sides and see what happens (I think I'm dialing in from
too damn many systems and using too darn many comm programs)...

I also use several different emulations, comm. programs, and screen sizes,
so I've written a couple of scripts to ease the process of setting things
correctly when I log in.

Script #1:  This is called "scrsize" and sets the size of the screen.
Invoke it as "scrsize 49 80", for example.  It can be used for resizing
the screen anytime during a session.

        #!/bin/sh
        stty rows $1 cols $2
        echo '<ESC>[r'
        clear

The echo command sends an escape sequence to the terminal to set the
scrolling region to the full screen.  It's specific to "vt" terminals,
I believe (vt100, vt102, vt200, etc.).  The <ESC> has to be replaced
by an escape character (control-[); I didn't want to use an actual
escape character in this response for obvious reasons.

Script #2:  This is called "setterm".  It prompts for the terminal
type and screen size, then initializes your terminal and sets row
and column values by invoking script #1.  Since it sets an environment
variable, it has to be *sourced* by your login shell and hence written
in the script language of that shell.  The following should work for
csh and tcsh:

        echo -n 'term='; set term=$<
        echo -n 'rows='; set rows=$<
        echo -n 'cols='; set cols=$<
        set noglob
        eval `/usr/ucb/tset -sQ`
        unset noglob
        ~/scrsize $rows $cols

Put the above scripts in your home directory, make scrsize executable
with "chmod +x scrsize", put the command "source ~/setterm" in your
.login file.  You'll be prompted for your terminal type and screen
size when you log in, and the scripts will do the rest of the work.

This looks like a good solution.  I'll give it a try when I get a
free moment to set it up :)

Hmmm...my work around for this was simpler: get rid of tset.  I really don't
want the initialization string sent to my terminal.  It isn't right.  And
the screen size in the termcap is wrong too.  So who needs "tset"?  Its
only remaining useful capability appears to be to do an "stty crt" (which
I would suggest should be the default for users on this system) so that
backspaces echo properly.

So currently my login does:

        stty intr '^C' kill '^X' erase '^?' crt
        setenv TERM vt100
        stty rows 57

And I can change by screensize with an "stty rows 64" and no other fiddling.
Scrolling region is always left as the full screen.

This response has been erased.

The general reason is that it sends an initialization string to 
terminals that need one and provides a fairly flexible means of
letting the user choose the terminal type on each login, useful
if one connects from different kinds of terminals at different
times.  But as Jan points out, it's rather obsolete -- most 
terminals nowadays don't need an initialization string, and there
are better methods for setting the proper terminal type.

Response not possible - You must register and login before posting.

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