This bug log was painful to read. People are mixing together TERM settings, LANG (I have no idea why UTF-8 keeps popping up, that's obviously not going to work on a vt220), customizations and options, the actual terminal attached, running within virtual terminals ('script' is one, not just tmux)... It's almost impossible to root cause a bug efficiently like this. You need to be much more methodical and first reduce the bug to the simplest reproducer, then document the exact setup. Instead of running under `script` to try to get logs, using `strace` would've been much more transparent and informative (showing you also the tty related syscalls while not interfering with the actual tty).
From the 'no output on a vt220' part I was already thinking 'I bet it's the serial port, not the TERM'. And indeed, misconfigured terminal size is something anyone who has ever connected to an embedded system over serial has experienced, though I didn't know the default setting was 0,0 (other shells interpret that as 80x25 or something like that by default).
It's good that they figured it out, but bugs like these show why solid troubleshooting skills are rare and very valuable. This could've been solved in 30 minutes with a strace log and some digging through the code.
Vt220 supports non-ASCII chars. It would be useful to use the Unicode equivalents internally and map them to an encoding the terminal recognizes on output.
Had those devices survived into the unicode era, that no doubt would have become a standard feature somewhere along the stty/termcap/terminfo/curses chain.
An absolutely mindbending amount of effort was expended back in the day trying to make terminal handling work in a portable way. People today think that having to support five different browsers is hard. Imagine a market populated by like 50+ different hardware terminals with only vaguely overlapping features and spotty standards compliance.
From the 'no output on a vt220' part I was already thinking 'I bet it's the serial port, not the TERM'. And indeed, misconfigured terminal size is something anyone who has ever connected to an embedded system over serial has experienced, though I didn't know the default setting was 0,0 (other shells interpret that as 80x25 or something like that by default).
It's good that they figured it out, but bugs like these show why solid troubleshooting skills are rare and very valuable. This could've been solved in 30 minutes with a strace log and some digging through the code.