42.5 Checklist: Screen Size Messed Up?

The termcap and terminfo (5.2 ) systems used to be the only place where the size of your terminal screen (number of lines and characters) was set. These days, screen-oriented commands like vi and more on most UNIXes need to work with window systems. Users can shrink or stretch their windows without changing the termcap or terminfo definition. Depending on the command and version of UNIX you're using, you can run into window-size problems even if you aren't using a window system.

Window systems don't cause all the problems though. "Classic" problems, such as files with lines that are longer than the terminal is wide, were around before UNIX did windows.

Here's a checklist of things to try. Once you figure out what's wrong and how to fix it on your terminal and version of UNIX, you'll probably be able to fix problems with other programs you run.

• Displaying or editing a file with lines longer than the screen is wide can cause strange problems if everything isn't set up right. There are two places that may try to split a line into pieces when it thinks that the line is too long. The problem, of course, is when these don't work together or one of them has a wrong idea about the line length:

  • Your terminal or window may be set to autowrap lines that would cross the right edge: The line is broken and the rest is shown beginning at the left margin on the next line below.

  • If you use a screen-oriented program like vi or more , they may wrap long lines. The termcap and terminfo definitions tell screen-oriented programs whether to wrap lines. (For more information, see O'Reilly & Associates' termcap & terminfo .)

  To find out what your terminal is doing, display a file with long lines like longlines (42.6 ) . The cat (25.2 ) and head (25.20 ) programs don't use termcap or terminfo -they spit the file directly to your screen. So, for example, a single 200-character line from longlines should be shown as three lines on an 80-column screen. You shouldn't lose any of the characters at either side. Two lines would look like this:

  % head -2 longlines
  
  
  1  45678901234567890123456789012345678901234567890123456789012345678901234567890
  12345678901234567890123456789012345678901234567890123456789012345678901234567890
  1234567890123456789012345678901234567890
  2  45678901234567890123456789012345678901234567890123456789012345678901234567890
  12345678901234567890123456789012345678901234567890123456789012345678901234567890
  1234567890123456789012345678901234567890

  If you see only two "chopped" lines, your terminal isn't wrapping lines. You may want to go into its setup mode and enable line-wrapping. If you do though, be sure that your termcap/terminfo definition lists the terminal as autowrapping. If your terminal autowraps but the termcap/terminfo definition doesn't say that, screen-oriented applications may try to wrap lines for you. Exactly what happens depends on the application you're using and your terminal. One common problem is that the screen may look double-spaced - each part of a single long line that's "wrapped" has a blank line after it. For instance, the longlines file might look like this:

  1  4567890123456789012345678901234567890123456789012345678901234567890123
  1234567890123456789012345678901234567890123456789012345678901234567890123
  1234567890123456789012345678901234567890
     ...

  In that case, both the terminal and the application are probably trying to wrap the lines for you. Usually, then, the application won't know exactly how many lines your terminal is displaying and will send twice as many lines as your screen can show. What a mess! Try to use another value of the TERM (5.10 ) environment variable that defines your terminal as autowrapping. These can have names that end with am or aw , like vt100aw . Or, if you want to dig in, it's not too hard to adapt your own termcap or terminfo definition from the standard system file. For more information, see article 41.11 or O'Reilly & Associates' termcap & terminfo .

• Your screen can be mixed up when a full-screen application-a pager like pg , for example - is displaying the standard output of some program. The program writes some messages to its standard error. These extra lines aren't counted by the application, but they show on your screen. If the application has a redraw screen command like CTRL-l you may be able to get a fresh copy of the lines from standard output. Or, you can pipe both stdout and stderr to the pager (13.4 ) .

• Some applications let you set their screen size in a configuration file or environment variable. For example, Berkeley mail (mailx (1.33 ) on System V) has a screen variable that might be set in its .mailrc file or in a system file like /usr/lib/Mail.rc . The vi editor has a window variable that might be set in your .exrc (4.9 ) file.

  Unless you set those variables correctly for all the terminals you use, you'll usually be better off to let the application set its own window size.

• Your version of UNIX may keep the screen size as part of the device settings. To find out, type the command:

  % stty size
  
  
  24 80

  (If that doesn't work, try stty -a ; look for rows  = and columns  = in the output.) The command shows that UNIX thinks your screen has 24 lines and 80 columns. Or, the screen size may be stored in environment variables called COLUMNS and LINES :

  env egrep	% env | egrep '(COLUMNS|LINES)=' COLUMNS=80 LINES=24

  If the current settings don't match your screen size (42.6 ) you can change the screen size settings. See the suggestions below.

• If UNIX doesn't know your screen size and your system has the stty size command, you can use stty to change the settings. For example, if your window has 43 rows and 80 columns, type:

  % stty rows 43 columns 80
  
  

  If applications are using the COLUMNS and LINES environment variables, just reset them (6.1 ) .

  NOTE: Any jobs that are stopped or in the background when you change the screen size may not work anymore because they'll still have the old window size. If that's a problem, quit and restart the applications or send them a SIGWINCH signal (below).

• If you're running xterm in the X Window System (1.31 ) , use resize . It asks your xterm to report (silently) on how big the window is now, then it resets the stty parameters or environment variables, depending on which your system needs. When it sets environment variables, resize needs to give commands to the shell. In the C shell, type:

  eval	% set noglob; eval `resize`

  (You don't need to use unset noglob (6.9 ) because resize outputs that command.) In the Bourne shell,

  $ eval `resize`
  
  

  Both of these are easier to use if you define an alias (10.2 ) or a shell function (10.9 ) named something like rs :

  alias rs 'set noglob; eval `resize`'
  rs() { eval `/usr/bin/X11/resize`; }

• In UNIXes that store the window size as part of the device settings (not in environment variables), here's another thing you can do. First, use stty to set the right sizes (see above). Then send a SIGWINCH (window changed) signal to the shell and/or job that has a wrong idea of the window size:

  % kill -WINCH $$
  
      Send signal to the shell
  
  % kill -WINCH %1
  
      Send signal to job 1
  

• In some window systems, you can make your window a little taller or shorter. That will reset things.

• You're using the telnet (1.33 ) command to log in to a remote machine. You didn't have trouble with the window size on your local machine - what's wrong? telnet probably didn't pass your correct window size to the remote host. If both the local and remote machines support rlogin (1.33 ) , use it instead. Otherwise, use one of the tips above to set the window size on the remote system.