termsize curses version does not work for me

[aivanise]

latest version does not work for me, tried both debian 11.3 and RHEL 8.6, serial console

for some reason getmaxyx() always returns 80x25

if it is working for you maybe rewrite it so if you get 80x25 from getmaxyx() fall back to non curses version as if someone had 80x25 terminal, he wouldn't be using termsize in the first place ;)

[ssokolow]

I noticed something similar with termsize.py and assumed it was something to do with my Konsole → gnu screen /dev/ttyUSB0 115200 8N1 → Armbian stack, so I did a similar patch.

I also discovered that it appears to be necessary to call get_terminal_size_curses before get_terminal_size_noncurses to avoid some kind of race condition which
results in rows, cols = list(map(int, re.findall(r'\d+', output)))
intermittently dying with an error about expecting to unpack 2 things
but getting 0.

[akkana]

Sorry, I haven't been able to reproduce this, so I'm not sure what's going on. It still works for me on Debian sid in urxvt, xterm and the console, and when sshed to a Raspbian raspberry pi from urxvt and the console.

get_terminal_size_curses() is always called first, and get_terminal_size_noncurses will only be called if the curses version fails.

It might help to see the actual error message.

People seeing failures: what is TERM set to? I've tried it with TERM=rxvt-unicode-256color, TERM=xterm and TERM=linux.

[ssokolow]

Here is my setup:

1. Konsole 19.12.3 from Kubuntu Linux 20.04 LTS
2. GNU Screen 4.08.00 (GNU) 05-Feb-20 from Kubuntu Linux 20.04 LTS
3. The Debian image for the Cubox i4Pro linked at https://solidrun.atlassian.net/wiki/spaces/developer/pages/197493654#Booting-form-an-SD-card
4. Connecting from the Kubuntu box to the Debian box over a serial console via screen /dev/ttyUSB0 115200 8N1, since I've never had the terminal dimensions not be set correctly when using SSH, so I had no reason to need any help with it.

With your stock script, I had to patch the shebang line because I only have python3 installed and didn't want to potentially complicate diagnosing future problems porting old scripts by setting python to point to python3 rather than python2. (I believe the official way to do that is to install the python-is-python3 package.)

Once that was done, with the default TERM=vt220, it "runs fine"... but the result is Reset the terminal to 24 rows, 80 cols when the terminal's actual size is 243 columns by 50 rows.

Using export TERM=xterm, export TERM=xterm-color or export TERM=screen has no observable effect aside from preventing the screen-clearing behaviour which occurs as a side-effect with TERM=vt220.

Commenting out the rows, cols = get_terminal_size_curses() and the associated try/except and unindenting rows, cols = get_terminal_size_noncurses() causes it to randomly choose between one of the following two outputs, with the aforementioned changes to TERM seeming to have no effect:

debian@sr-imx6:~$ ./termsize
                                                                                                                                                                                                                                                  Reset the terminal to 50 rows, 243 cols
debian@sr-imx6:~$ ./termsize
                                                                                                                                                                                                                                                  0;243RTraceback (most recent call last):
  File "/home/debian/./termsize", line 91, in <module>
    rows, cols = get_terminal_size_noncurses()
  File "/home/debian/./termsize", line 82, in get_terminal_size_noncurses
    rows, cols = list(map(int, re.findall(r'\d+', output)))
ValueError: not enough values to unpack (expected 2, got 0)

Note the scrollbar on that code block. In both cases, the first line of output has a ton of whitespace before it. In fact, it appears to consistently be one less than the length needed to make it wrap, so it appears to be eset the terminal to 50 rows, 243 cols and ;243RTraceback (most recent call last): on a terminal that's doing line-wrapping.

Adding a print(repr(output)) reveals the contents of output that are causing the ValueError to be \x1b[ as opposed to \x1b[50;243R in the successful case.

[aivanise]

for me I have tried WezTerm and stock Terminal on on OSX, as well as gnome-terminal on Ubuntu and they all do the same thing, getmaxyx() always returns whatever the terminal is set to (i.e. the output of stty -a), which is by default 24,80.

I think thats why it works after using the noncurses version as noncurses sets it to correct values.

TERM is set to vt220, but tried linux, rxvt-unicode-256color, screen, no difference

on the host system python is 3.9.2, debian 11 if it makes a difference

[bam80]

Sorry, I haven't been able to reproduce this, so I'm not sure what's going on.

@akkana, easy way to reproduce is to run some ISO (Live or installer) in VM, e.g.:
https://download.fedoraproject.org/pub/fedora/linux/releases/41/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-41-1.4.iso
Please tell us if you need help with the details.
Thanks.

PS:

$ qemu-kvm -serial stdio ...

console=ttyS0 kernel cmdline