why doesnt vi resize itself in xterm and other weirdness

Sean Eric Fagan sef at kithrup.COM
Sun Jan 13 21:04:40 AEST 1991


In article <37871 at cup.portal.com> DeadHead at cup.portal.com (Bruce M Ong) writes:
>Hi -
>	I am playing around with a big monitor (corner stone) on the
>ISC2.2 unix. The resolution is 1600x1024 or something. I have a vi
>running in an xterm, but when I resize the xterm and restart vi, 
>it will not chanage its window size according to the size of xterm. My
>TERM is set to xterm. Why is this so? My sparc station doesnt seem to do 
>this at all.

Your TERM variable, in this case, doesn't matter.  Under BSD-based systems
(and some SysV systems, but not all, by any means), resizing a window causes
the window program (xterm, in this case) to send a SIGWINCH to the process
group running in that window; if the program has been written to accept it,
it will then do an ioctl(fd, TIOCGWINSZ, &buf) to get the size of the
window.  (I think that's the ioctl.)

However, SysV does not have this for normal pseudo-tty's (which is what most
xterms use).  The STREAMS-based ptys, which are unsupported (and, I believe,
undocumented), *do* support the necessary ioctl, but I don't know of any X
implementation that uses them.

>	Another problem is that if you do rlogin and then vi on the
>remote machine from an xterm, the vi window is always 25x80 no matter
>what size your xterm is. Is there anything I should fix in xterm termcap?

export LINES=<lines> COLUMNS=<rows>

SCO ships a program called resize, which I tend to use as

	eval $(resize)

(I use ksh); this spits out a TERMCAP, I believe, as well the LINES and
COLUMNS variables.  (I don't know if resize is a standard program or not.)
Note, however, that you would have to quit vi to take advantage of a resized
window.

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef at kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.



More information about the Comp.unix.sysv386 mailing list