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 <i>obviously</i> 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).<p>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).<p>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.
I also use a VT520 on a regular basis, and support nowadays is limited.<p>- Since it cannot display Unicode, i have to wrap most things in a screen or tmux session to have unicode characters replaced<p>- Flow control is a hard requirement - just a single thing like a irssi screen scroll is enough to fill the buffer terminal-side<p>- tmux is hard-coded to disable software flow control, so i have to make sure the RTS and CTS lines are connected for hardware flow control or switch to using screen<p>- In fact, for hardware terminals, screen makes much more sense than tmux<p>- The connection is unstable above 38400, just single missing bytes cause TUI applications to render incorrectly<p>- I had to ship a custom terminfo with my dotfiles for the status line (what is the window title in xterm) to work correctly<p>Procrastinating in IRC and mailing works fine via irssi and mutt. Developing is a bit harder since i am used to mouse-based clipboards.
I like how this bug report captures how much we've lost :-).<p>Basically the bug is that VT220's are not UTF-8 capable display devices. What is worse, when you send them UTF-8 sequences they interpret them as VT200 sequences and as a result oddness can and does occur. I haven't tried fuzzing one of my VTxxx terminals but I suspect there are likely cases where you can hang the terminal with the right character sequences.<p>Of course, most people, perhaps > 80%, working on open source maintenance have never actually touched a terminal. Many have lost any idea of what "TERMCAP" is, or the difference between "Smart" and "dumb" terminals, and what escape codes do what. For most, "terminal" is a program that runs and always responds in a way you would expect it to respond (which is typically a variant of ANSI terminal specs). Not that they have ever tried to get their shell to run on a Beehive or Hazeltine or Adds terminal either.<p>At one of the west coast vintage computer festivals I had a VT320 connected to a Linux box and the younger adults there who played around with it were appalled at both the lack of colors ("How do you know what files are directories?") and the pitiful number of lines and columns ("I feel like I am inside a coat closet!") It was funny, and sad. Sad because my memories of how great it was to have a terminal that could do line insert so when editing files over a 1200 baud modem it still felt fast, were now pitiable.
In 2001 I had a collection of old DEC terminals from Ebay arranged on my desk, all hooked up to a FreeBSD box over serial. They were already antiquated back then but still really useful - I had email and IRC running on separate terminals and kept the main graphical display for browsing. It was all fun and games until one day I came back from lunch to see everyone in the whole building standing outside with the fire department. One of the capacitors on the motherboard of an old VT320 blew and set off the smoke alarm. After that I wasn't allowed to bring my own hardware to work anymore.
Author of the issue is Drew DeVault, by the way, the author of sr.ht and many other cool things <a href="https://git.sr.ht/~sircmpwn" rel="nofollow">https://git.sr.ht/~sircmpwn</a>.
> Found the issue - $TERM was incorrect, and LANG=c helped as well. Thanks! For the curious, it is a real vt220, and I have it connected to Arch Linux (fully up to date, well, except for the hardware). It's connected with a DB29->DB9 null modem cable I made from a breadboard, a bunch of jumper cables, and a DB9 header, which is in turn connected to a simple RS232 USB serial cable.
I saw this and thought "of all the people reading this, I'm one of a very few who is looking at a vt220". But then I turned it round on the shelf and noticed it's a vt320.
When writing a terminal emulator for my editor/IDE last year it was impossible to find a standard. I implemented the classic vt100? standard but nothing worked. The standard is basically "what xterm does" so i had to check what xterm does for the same command sequence and then mimic that.
BTW, you can cable an old-school RS232 terminal much easier than in the photo there. The terminal will most often have a DB25 connector for RS232 to the host (your computer), and there are cheap cables on eBay with integrated adapters that will turn RS232 one one end to USB Serial on the other. These cables are usually DB9 to USB-A, and may sometimes include a very common DB9-to-DB25 adapter. They cost only several dollars on eBay (if possibly trojan USB devices aren't a concern).<p>I used such a cable for testing a silly terminal library with some vintage terminals: <a href="https://www.neilvandyke.org/racket/charterm/" rel="nofollow">https://www.neilvandyke.org/racket/charterm/</a><p>Warning: If you see a cable that's DB25 to USB-A, check that it's an RS232 serial adapter, rather than PC parallel printer port adapter. Early PCs used 25-pin connectors for both serial and parallel interfaces, maybe because the DB25 connector fit better out the back of the card cage than a Centronics parallel printer connector would (and the DB25 connector on the PC would then require a cable that went to the Centronics connector on the printer), and just distinguished the serial and parallel DB25 connectors by gender. Eventually PCs moved RS232 to a DB9 connector.
The thing that strikes me about this issue is how unhelpful and, well, rude the author is. Terse, minimum viable answers to questions, no contextual detail even when it is obviously needed, and an air of expectation, as if the maintainers owe him a solution.
Could someone add support to automatically test this on an emulator?<p>Or, better yet, put in checks that prohibit future code from including those bad char seqs?<p>This is bigger than the cool pics of nostalgic hardware.<p>It reminds me of other compatibility problems over the years like:<p>1. Microsoft choosing the opposite slash and a different way of doing CLI options via slash vs dash.<p>2. Windows, Apple, and Linux not agreeing on a good filesystem and method of network access and supporting it together. Incompatibilities have wasted a great deal of time, and it’s unreasonable to think that every IT department will make changes to allow everything to work smoothly.<p>3. Microsoft Office, Lync, Skype for Business, Remote Desktop, etc. not including 1:1 functionality in the macOS versions of their products. This is evil since the user can’t do things that others can. Similarly, Microsoft changed menus and where things are located between versions. Should a wooden chair be the Mac version of a couch because they’re both butt-compatible? Should marmite be the next version of strawberry jam because they both spread on toast and are tasty?<p>4. Programming language tools and libraries that favor one OS over another or one well-used database over another.<p>While supporting compatibility can be a timesuck, here we have fish shell spending the time supporting a minority, which is great.<p>But large companies, leaders of small well-used projects, and everything in-between are self-sabotaging the future of all life on our planet by wasting others’ time because they want to do their own thing or want to make people not like some other company’s product.<p>Incompatibility and not working together isn’t healthy competition, beneficial capitalism, or good business. It’s going to kill us.
I'd argue that we shouldn't be adding code (in general, not limited to fish) to support old hardware such as this (or see the crazy list of systems supported by OpenSSL)<p>A lot of pain in systems comes from unbound backwards compatibility