PuTTY / xterm / line-wrapping when "maximized"

[Dave Lindquist <@.com>]

Anyone else ever encounter this?

I've a weird but with Putty, xterm, and just about anything else I've tried
for terminal programs.

If you resize the window of the terminal manually, everything works
perfectly -- the new size of the window (chars x chars) is communicated
properly to the other end, and line-wrapping works perfectly.

However, if you maximize the window, something different happens. ncurses
apps, etc all recognize the new size and use it, but the Linux (Gentoo)
command prompt still tries to wrap at the wrong column (the original width
before being maximized). This, of course, causes lines to overwrite each
other, and all hell breaks loose if you use the backspace key.

Any ideas what the heck could cause this, and what one could do about it?

TIA!

[Jacob Nevins]

Post by Dave Lindquist <@.com>
I've a weird but with Putty, xterm, and just about anything else I've tried
for terminal programs.
If you resize the window of the terminal manually, everything works
perfectly -- the new size of the window (chars x chars) is communicated
properly to the other end, and line-wrapping works perfectly.
However, if you maximize the window, something different happens. ncurses
apps, etc all recognize the new size and use it, but the Linux (Gentoo)
command prompt still tries to wrap at the wrong column (the original width
before being maximized).

PuTTY (0.57) appears to be sending the appropriate window-size message
for the protocol regardless of how the window is resized.

There's a common problem where the SSH server (or whatever) only sends a
window size change notification (SIGWINCH) to the foreground process, so
if you resize while another process is running, and then exit that
process, the shell doesn't notice that the window size has changed.
Running "kill -WINCH $$" will then cause bash to notice what has
happened.

I can reproduce this on Debian woody with bash as my shell and lynx in
the foreground, whether I resize by maximising or by changing the window
size, over SSH and Telnet protocols.

[Thomas Dickey]

Post by Jacob Nevins
I can reproduce this on Debian woody with bash as my shell and lynx in
the foreground, whether I resize by maximising or by changing the window
size, over SSH and Telnet protocols.

But lynx doesn't resize dynamically, so (unless you're pressing ^R to update
the display), you won't be able to test that. That's done to limit network
activity, etc.

Most text editors will resize dynamically - that's a better test.

[Jacob Nevins]

Post by Thomas Dickey

Post by Jacob Nevins
I can reproduce this on Debian woody with bash as my shell and lynx in
the foreground, whether I resize by maximising or by changing the window
size, over SSH and Telnet protocols.

But lynx doesn't resize dynamically, so (unless you're pressing ^R to update
the display), you won't be able to test that. That's done to limit network
activity, etc.

Since I'm demonstrating a problem with the shell, what the foreground
process does should be immaterial.

But, just for you, I reproduced it with vim too.

[Mike Castle]

Post by Dave Lindquist <@.com>
If you resize the window of the terminal manually, everything works
perfectly -- the new size of the window (chars x chars) is communicated
properly to the other end, and line-wrapping works perfectly.
However, if you maximize the window, something different happens. ncurses
apps, etc all recognize the new size and use it, but the Linux (Gentoo)
command prompt still tries to wrap at the wrong column (the original width
before being maximized). This, of course, causes lines to overwrite each
other, and all hell breaks loose if you use the backspace key.

I'm surprised that it works with resizing the window. My guess is that
you're performing an incorrect experiment.

Either way, this bit from the Bash FAQ addresses the question:

E11) If I resize my xterm while another program is running, why doesn't bash
notice the change?

This is another issue that deals with job control.

The kernel maintains a notion of a current terminal process group. Members
of this process group (processes whose process group ID is equal to the
current terminal process group ID) receive terminal-generated signals like
SIGWINCH. (For more details, see the JOB CONTROL section of the bash
man page.)

If a terminal is resized, the kernel sends SIGWINCH to each member of
the terminal's current process group (the `foreground' process group).

When bash is running with job control enabled, each pipeline (which may be
a single command) is run in its own process group, different from bash's
process group. This foreground process group receives the SIGWINCH; bash
does not. Bash has no way of knowing that the terminal has been resized.

There is a `checkwinsize' option, settable with the `shopt' builtin, that
will cause bash to check the window size and adjust its idea of the
terminal's dimensions each time a process stops or exits and returns control
of the terminal to bash. Enable it with `shopt -s checkwinsize'.