Wrong row / col number when connecting via SSH

[Sascha Vogt]

Hi all,

great to see some improvements to iTerm as it always was my favorite
terminal emulator.

Nevertheless I currently have an issue with iTerm and SSH, which I
cannot figure out.

If have my terminal set to 100x32 as default, but when I connect to my
SSH server and reattach screen, the tools in there only think the size
is 80x24 (visible for example if you open irssi or other ncurses tools
which draw lines around the "screen". This issue is easily fixed by
manually resizing.

Anyone knows what might be wrong?

Greetings
-Sascha-

[George Nachman]

If you run stty -a before ssh, does it report 100x32?

[Sascha Vogt]

Hi,

Am 04.06.11 20:31, schrieb George Nachman:

> If you run stty -a before ssh, does it report 100x32?

Yes it does:
stty -a
speed 38400 baud; 32 rows; 100 columns;

Greetings
-Sascha-

[George Nachman]

Hm, not sure what's going on here. If your tty knows how big the
window is then SSH will communicate that to the remote host. I suspect
you'd get the same result in Terminal.app and that this is a problem
with your ssh client or host. Try sshing from a different Mac to see
if it's a client problem; try sshing to a different host from this
same machine to confirm that it's a host problem.

[Tom Feist]

Have you tried fiddling with the checkbox in Preferences -> profiles -
> Window.
Right at the bottom there's a 'disable session-initiated window
resizing',
which might help. I think Screen specifically tries to restore your
previous
window size, unless you tell it otherwise. See man 1 screen:

"-A Adapt the sizes of all windows to the size of the current
terminal.
By default, screen tries to restore its old window sizes when
attaching to resizable terminals (those with "WS" in its description,
e.g. suncmd or some xterm)."

Also, does:

$ echo "Rows: $LINES, cols: $COLUMNS"

show the correct values (both locally and remotely)?

Failing that, does anyone know if it's our responsibility to send
SIGWINCH on resize,
or if some other layer of the massive crusty termios stack is
responsible?

I can only find one reference to kill, in Session/PTYTask.m, which is
only
ever called with SIGHUP (line ~714). If we're supposed to be sending
it and aren't,
that might be the problem.

Cheers,

Tom.

[Vincent Wang]

I got the same window size issue here. I don't ssh to another server
and run screen, I just attach to a local tmux session. The weird thing
is some windows have the correct size, but some windows do not.

I did not meet this issue within Terminal.app before.

I am not sure how to reproduce this issue stablly, but it is very easy
to happen. I have tried to set "Disable session-initiated window resizing"
option on and off, but no luck.

* George Nachman <gnac...@llamas.org> [2011-06-04 15:55:18 -0700]:

--
"The tool that save the most labor in a programming project is probably a text-editing system" -- <<The Mythical Man-Month>>

http://blog.linsong.org

[Derek Fawcus]

On Sun, Jun 05, 2011 at 08:49:06AM +0100, Tom Feist wrote:
> Failing that, does anyone know if it's our responsibility to send
> SIGWINCH on resize, or if some other layer of the massive crusty
> termios stack is responsible?

The kernel sends it.

But it only sends it to the foreground process group for the pty.

.pdf

[Sascha Vogt]

Hi all,

first of all, thx to all for helping with the issue.

Am 05.06.11 00:55, schrieb George Nachman:

> Hm, not sure what's going on here. If your tty knows how big the
> window is then SSH will communicate that to the remote host. I suspect
> you'd get the same result in Terminal.app and that this is a problem
> with your ssh client or host. Try sshing from a different Mac to see
> if it's a client problem; try sshing to a different host from this
> same machine to confirm that it's a host problem.

I think I found the culprit. It's luit *grml*
Terminal.app showed the same issue and locally everything was ok. So i
tried a plain SSH connection and there the $ROWS and $COLUMNS was
correct too.
Seems not to be a general problem with luit though, as on multiple Linux
versions everything works fine.

Thx again and sorry for bothering the wrong list ;)

Greetings
-Sascha-

[Pelle Johansson]

I didn't see the start of the thread, but this particular case sounds like you have multiple ttys with different sizes, attached to the same tmux session. At least for screen, only the first tty attaching will set the screen size.
--
Pelle Johansson

[Vincent Wang]

I think my issue maybe cause by following senario:
1. start a new tmux server with several sessions launched
2. during the starting process, I switch to full screen mode
3. some windows have the correct full screen size, but some windows don't

I will send more details if it can be reproduced.

Thanks.

* Pelle Johansson <pe...@morth.org> [2011-06-05 20:35:45 +0200]: