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.
I also use a VT520 on a regular basis, and support nowadays is limited.
- Since it cannot display Unicode, i have to wrap most things in a screen or tmux session to have unicode characters replaced
- Flow control is a hard requirement - just a single thing like a irssi screen scroll is enough to fill the buffer terminal-side
- 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
- In fact, for hardware terminals, screen makes much more sense than tmux
- The connection is unstable above 38400, just single missing bytes cause TUI applications to render incorrectly
- I had to ship a custom terminfo with my dotfiles for the status line (what is the window title in xterm) to work correctly
Procrastinating in IRC and mailing works fine via irssi and mutt. Developing is a bit harder since i am used to mouse-based clipboards.
Honest question - is this due to professional requirements, or is this like a masochism thing? I just don't understand why you'd go through the trouble willingly.
I still use serial terminals too, also a VT520. The 520 is a bit more modern than the others, it allows PC keyboards (PS/2) and higher speeds. The vt220 would already choke on faster streams than 19200 IIRC. It also has more spacious modes than 80x24.
I don't use it for everything but one of the nice things is that it is easy to concentrate on something. No chance of procrastinating by opening facebook :)
And as a debugging / recovery tool it's sometimes handy, when the whole GUI side is crashed I can still kill some processes. Sometimes I can't switch to a text CLI console even.
And the retro feel simply appeals to me. I know it's not for everyone.
I've actually been thinking of making something like a modern terminal. Like a Raspberry pi with an SSH client in baremetal so it boots really quickly, with easily switchable font sizes etc. But it's too much work I don't think I'll get around to it. Maybe I'll skip the baremetal part and just go for fbterm on a really cut-down Linux distro, that might work.
>I don't use it for everything but one of the nice things is that it is easy to concentrate on something. No chance of procrastinating by opening facebook :)
Lynx works over m.facebook.com, and slashem/frotz is a great time waster :D. Once you play slashem as a doppleganger monk, or play Anchorhead, Spider and Web, or Slouch over Bedlam under Frotz, that stance is not taken as granted.
Once you've got it running, it isn't (usually) any trouble. Doesn't everybody have a drawer full of null-modem adapters, DB9-DB25 adapters, RJ11/RJ14/RJ45 => DB9 cables, and a Zoom 14.4K modem that probably still works if the AC-DC adapter can be found?
Depends on your location of course. In the USA I believe the median age is 38 and in Japan it's 48. But globally speaking, at 35 you've got one foot in the grave already :=)
Most of this, plus USB-serial adapters (I've heard that PCs with native serial ports are now considered "professional" equipment), plus some more exotic ones. A decade ago I used to use port switching boxes and to assemble adapters like Lego bricks to connect the square peg with the round hole . But that's only because I work in embedded.
>>I've heard that PCs with native serial ports are now considered "professional" equipment
I mean, laptops, sure. But PCs I think most still have a COM port. I bought a "gaming" X570 motherboard recently and there's still a COM header on it, I'd need to buy the port itself but the mobo does support it natively.
Microsoft started an initiative in the late 90s to abolish "legacy" ports from PCs including serial, parallel, and PS/2. RS232 is not something you can expect on consumer-grade equipment.
I find the VT520 more pleasant to look at than a LCD screen. The VT has a CRT and no backlight - when its dark, the screen doesnt "glow". The brightness and contrast are adjustable via two potentiometers, allowing eye-strain-less reading during the night.
The terminal bell makes an audible beep, i use that to signal stuff happening in IRC.
Probably because its a CRT, it also doesn't inhibit me from getting tired in the late hours like a phone or laptop does.
Last but not least, the hackability: You can interface the VT via uart, and thus can use it as user interface to an arduino or other retro computers. KVM-like switches are also easy to DIY for serial connections.
Not a terminal user, buy VTY and framebuffer. I use a sound bell with a tmux config for that, but with a sound file from the infamous Sun Multimedia mirror from sunsite.
On being tired, I can set the laptop brightness too with light(1).
There aren't many practical reasons to do it these days, but they are beautiful machines and a joy to use. While you won't have a VT 220 as your daily driver, it's perfectly good to keep one in place of one terminal window.
It's a personal thing, but I am not that annoyed by the delay between a key press and a character comes up on the screen. OTOH, I still remember how pleasing were 3270's compared to serial terminals on 9600 shared links.
My dad said a big advantage of the hjkl navigation keys in vi were that they were single character. The arrow keys were multi character, so if the escape character got dropped, you would end up sending control codes as plain text
I like how this bug report captures how much we've lost :-).
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.
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.
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.
> Basically the bug is that VT220's are not UTF-8 capable display devices.
This was not the bug. I suspect that you didn't get the end, and I don't blame you. The bug was that the terminal reported zero rows and columns. A "simple" stty command made it work.
Thanks! So two years after it was filed, and a year after it was closed, another user figures out on a different bug that the Linux psuedo device initializes size to 0, 0? That is super odd.
What is more odd, is that the number of lines and columns are in both the termcap file and the terminfo database for the vt220, and in the bug the user said they had set TERM to be vt220, which if you do an infocmp after setting will show you it is a 24 line x 80 column terminal. And yet the user krader1961 has them going through a stty command to set the values to 24 x 80? That "fix" just raises more questions than it answers. Why doesn't stty respect termcap/terminfo? Why does fish see 0,0, and what is going on with terminal support in general?
`ls -F` helps with this on terminals without color.
> "I feel like I am inside a coat closet!"
Some terminals do offer higher character resolutions than 80-by-25.
> 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.
I use a terminal on a somewhat regular basis (an IBM 3151 emulating a VT100, connected to a Raspberry Pi running FreeBSD).
It can be a great tool for learning Unix command line fundamentals thoroughly (a prime example of blub studies [1]), and as you get comfortable with it, you might find it useful for deep work (George R.R. Martin's use of WordStar 4.0 on DOS [2] is a famous example of modern-day usage of text-mode computing, which isn't the same as using a hardware terminal on a Unix machine, but close enough in spirit).
The caveat is that it does require patience and commitment to the process, which is tough when more convenient and capable user interfaces exist. Oftentimes I'll look up documentation on my phone while using the terminal, since it's simply more convenient than trying to navigate through modern websites on a text-mode browser.
Yeah I remember those green phosphor ones that we had in one of our computing centers on the campus. Alongside them there were pure IBM X Windows terminals, connected to a DG/UX server.
On a similar note I find similar lack of experience understanding what is possible with something like ESP32, given the computing power we had at the early 80's, and the polyglot environments that were already available back then.
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.
> 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.
I bought mine 18 years ago on eBay with the idea to expose my son (who had just been born) to old school programming with a VAXStation I also bought at the time and Sara Baase's book VAX Assembly Language Programming. Needless to say the plan hasn't worked out but I still have the VAX and vt320 and the book, so there's that. Son is off to study Economics..
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).
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.
Er, if the person who just emailed me something about charterm and ANSI color happens to see this comment, could you please resend your email? (The email was lost due to an MUA & IMAP problem as I was moving it out of the spam folder. I always reply to emails about open source.)
Using a real VT220 as a terminal in the 21st century certainly violates the principle of least astonishment. Even backwards compatibility should have its limits.
Continually repeating something does not make it true.
The default terminal size is 80 columns by 24 rows. Making an assumption the rows/columns of a terminal are zero is certainly surprising and unreasonable.
Some questions;
Why is fish not determining the defaults from termcap/terminfo?
If you put hardware designed to do the job of a terminal on a serial line, you expect software that is supposed to be command line based to just work (according to the issue in the post it doesn't work with the Linux VT console either)
Furthermore according to a similar issue; a contributor shows their hubris of ignoring terminfo.
> Serial consoles basically date back to the days of hardware terminals, like a physical DEC VT220, when you could trust the information about columns and rows in the terminfo definition.
I can see your point and agree with it: you can connect hardware that speak serial and use it to connect software that speaks VT220. Looking from this point of view, the hardware and software protocols are correctly assigned, everything is perfectly predictable and normal, and therefore this setup should surprise or astonish no one.
At the same time, I have a different point: this approach is definitely NOT in my personal catalogue of ways in which modern shells are interfaced with nowadays. Using an antique VT220 over a breadboard serial adapter is a unique hack, rather than something used every day, and therefore this setup is perfectly capable of surprising and astonishing people.
For me, the above two points of view don't collide with one another.
It's much more common to have a VT220 on a wheeled stand that you can bring over to the rack, with a set of cables already made up. No breadboards! That's amateur hour.
Or, fairly frequently, one VT220 hooked to a serial terminal concentrator that lets you select which of the 32 or 48 machines you want to be connected to.
Or a VT220 emulator in that smart serial terminal concentrator, that's addressable by SSHing in.
Or a VT220 emulator in an IPMI access point directly in each server, that's extremely common. SSH in, then connect to the serial terminal.
Emitting UTF-8 when the settings clearly say "no UTF" is a bug, no matter if a real VT220 is on the other end, or something else that doesn't understand unicode (which is still quite possible, even today). It's even a bug if unicode actually works on the other end (but in that case, nobody notices).
Yes, that's another issue that luckily seems to have been fixed in the linked bugticket.
Still, using antique hardware for interfacing with modern systems is something that would surprise me if I found it used in the wild. I know that the standards are well-defined and that the software support is there - it just certainly isn't the norm.
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.
He did not say "please fix". He also explained the exact issue that he encountered on the exact hardware that he used. Simply saying "patches welcome" would not clarify whether you are interested to help this person to figure out what the issue is.
There was nothing rude in the comment. It stated the problem: fish wasn't working in a VT220 (you have to read the title of the ticket to understand it). The rest of ddevault's comments were actually quite positive and friendly and there was zero entitlement. There was a lot of nostalgia.
I am the author of this issue and I don't really know what you're talking about. Terseness is something I value in bug reports as a maintainer myself. I don't want to read someone yarning on about the breakfast they were eating when they encountered a bug. I want them to tell us everything they know, and then nothing else. The pattern I did here - create a record of the bug with what I know, then investigate it on my own and update the discussion when I have more information or a solution - is also something I like to see as a maintainer.
Rude, entitled users is definitely a problem maintainers have to face. Here's a better example:
I think you were excessively terse. Nobody wants to know what you had for breakfast, but given the nature of the bug, clearly staring and restating the state of LANG, TERM, any intercepting terminal emulators, and how you were running this (on a serial try), would've helped narrow down the bug.
Your initial report started with an incorrect premise - fish does not work on a vt220. The real bug ended up being that fish does not work on Linux serial ttys. That's fine - we all make these kinds of mistaken assumptions about bugs - but it's here where mentioning all the details helps.
For example, without info about how it's hooked up via serial to a getty, it's unlikely someone unfamiliar with these setups would think about the possible consequences of that. And without mentioning the state of TERM, the bug is ambiguous: does fish not work on a physical vt220 with some settings, or does fish not work with TERM=vt220? Those are two different problems.
Excessive verbosity is fluff, but excess brevity leads to information loss. Some redundancy is required to ensure the meaning gets across. This is human error correction.
You weren't rude or entitled, but everyone on that thread, yourself included, displayed less than ideal bug reporting and handling skills. Things could've gone much more smoothly.
I don't think you were rude in the bug report, but I think there's an issue where if something is described with lots of brevity, even if accurate, it's hard to know if what was said is really what was meant, since there's enough bug reports that aren't careful about their language that you can't really trust someone when they just say "it just hangs". So in that case a more detailed description/picture/whatever of what exactly the error looks like is helpful even if technically it can be described in one sentence
He refers to the initial issue text without anything there. I know that it‘s best to create an issue with context and description. The approach of doing that somewhere in the thread is new to me.
imo, it,s better to make note of an issue than not at all, to get the ball rolling. the first post provided enough info to begin investigating.
tbh, few things annoy me more in foss world than a mandatory 20 questions form and process when reporting a bug (or feature request) which requires much less to communicate clearly. i don,t think that,s user friendly at all, and in me opinion it is shifting qa,s work onto the user.
With FOSS, the economics are very different than with paying customers. It’s fair to ask a FOSS user to go to a lot of effort to file a bug or request hand-holding support; the developers are not getting paid, so asking to user to work harder to make life easier for the developer is perfectly fair.
it might be ,,fair,, but it,s also a failure to be addressed, a missed opportunity to improve the software, which turns into a poor experience for the user.
i think the missing piece is grassroots support for individual users by the technically literate elite.
Could someone add support to automatically test this on an emulator?
Or, better yet, put in checks that prohibit future code from including those bad char seqs?
This is bigger than the cool pics of nostalgic hardware.
It reminds me of other compatibility problems over the years like:
1. Microsoft choosing the opposite slash and a different way of doing CLI options via slash vs dash.
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.
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?
4. Programming language tools and libraries that favor one OS over another or one well-used database over another.
While supporting compatibility can be a timesuck, here we have fish shell spending the time supporting a minority, which is great.
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.
Incompatibility and not working together isn’t healthy competition, beneficial capitalism, or good business. It’s going to kill us.
1. That's a symbol conflict, dating back to TOPS-10 that used forward slash for option separators[1]. \ was picked instead as it was shift-free as well, and directly opposite / on IBM Model F keyboards[2].
2. All those platforms have supported mutually compatible formats for as long as that has been relevant (that is, after some standardization on network hardware). That local variants stems from different OS's having different features that need support. E.g., Windows' complex ACLs vs. POSIX permissions (support for ACLs on UNIX-like platforms came later).
3. Office for Mac was a product developed by an entirely different team, having no relation to the regular office products. It's natural it was not identical. However, the solution here is not to force Microsoft to make 1:1 products for all platforms. It's to let alternatives grow: No one needs nor wants Microsoft Remote Desktop for Linux. We have FreeRDP, Remmina, and others. Don't monopolize computing.
4. You can either try to hide an OS and inevitably favor one over another (thereby significantly crippling the others), or you can expose everything (which usually leads to complaints about how much work it is for the developer).
1. It could have and still could be fixed. WSL commands and syntax are not yet integrated as an optional standard command shell. It’s separate and not equal.
2. Mutually compatible doesn’t solve all of the time wasted having to reformat as FAT32 or NTFS or to configure and support multiple filesystems like CIFS and NFS.
3. MS calls it Office. It’s neither the same team nor the same product. The macOS versions of the product are crippled with less configurability and fewer expected features. MacOS Remote Desktop provided by Microsoft is not equivalent to RDPing from Windows 10. And why shouldn’t you have the same product available for Linux? How do you know what those users want?
4. Another option would be to collaborate.
My point is not that anyone specifically dropped the ball, but that incompatibility and some kinds of changes waste time and resources.
Healthy competition is doing the best you can do, not tripping your opponent or excluding them from the race.
1. You can use UNIX style slashes in NT and it works fine. It’s just the default is to represent them using \ because CP/M and DOS originally used / as flag prefixes back before their respective file systems supported hierarchical directories.
To be honest your point is a little like moaning that Windows 10 doesn’t use GRUB or that FreeBSD doesn’t use systemd. Sometimes those differences are the differentiators, ie part of the OS design, and thus why you’d pick one OS over another OS.
2. CIFS and NFS is a protocol not a file system. Also see answer to point 1.
3. Product names are just another form of metadata. If you want 1st party Microsoft support then naturally you’d use a Microsoft operating system. Also see my reply to point 1.
4. You’re not asking for collaboration though. You’re asking for uniformity. Collaboration is different solutions that agree on supporting the same standards. Uniformity is when the same solutions are pushed on every platform. The later is a monopoly and that is very the antipathy of what Linux stands for.
Microsoft actually tried to fix it in DOS 2.0 with SWITCHCHAR. In CONFIG.SYS, you could specify SWITCHCHAR=/ or SWITCHCHAR=-, and then there was an API (INT 21,37) programs could call to find out which to use.
However, they pulled this feature from the 2.0 documentation, and then mostly removed it in 3.0 (some vestiges remained, but it was non-functional). I think the big problem they faced was that while programs shipped with DOS would respect the SWITCHCHAR setting, third-party programs wouldn't (at least until new versions using that API were released). I think they found out that it was too late and all too hard due to the backward compatibility constraints with the already (even by then) vast base of existing DOS software.
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)
A lot of pain in systems comes from unbound backwards compatibility
> Specifically, (pseudo-)serial devices, like the Linux console VT, initialize the rows and columns of the tty device to zero. That confuses fish since it now believes that nothing will fit on a line. Fish expects to be running inside a terminal emulator (xterm, konsole, iTerm2, etc.) which sets the tty width and height to the correct values.
So it's not only old hardware. It applies to modern hardware when you're using console to access a Linux server, which is not at all uncommon for data centers or headless servers.
This is why I love old hardware, even as a relatively "young" person in tech. It really keeps you disciplined and honest with your code. I have three older Xeon machines with very bad specs that I use as a Kubernetes cluster, and it's where I test a lot of my deployments. If whatever I thrown on it will run well, then it'll be blisteringly fast on an AWS server.
As a software developer, I politely disagree with your view. Some of the core standards powering UNIX/Linux is stable since eternity. Implementing these standards well enables a ton of backwards compatibility out of the box.
There are libraries which still protect their PDP-10 compatibility despite being maintained and refactored for current generation systems.
OTOH, every good software should build upon its foundation. When you have good foundation and a good interface to it, touching it is almost unnecessary in the long term.
It's not just a matter of backwards compatibility, but also forwards. Right now the common term type is xterm (or variants thereof like xterm-256color). 20 years ago it was vt100. Will it still be xterm in 10 years from now? Considering Xorg itself is claimed obsolete by its own maintainer makes me wonder if it will be.
Good thing we already have a mechanism to support smooth alternatives for terminal types.
While I personally use `tput` in scripts where it matters, I think an argument can be made that effectively all terminals now in use support ANSI X3.64 aka ECMA-48 aka ISO/IEC 6429. The 37-year-old VT220 does.
The greater sins I see today are assuming line length and assuming background colour.
I think that pain can also be a symptom of bad architecture - i.e. a lot of systems are clearly made in the image of their forbearers, so it shouldn't be totally impossible to restrict a subset of behaviour to make it work on (say) a physical terminal instead of emulated one.
"We"? Are you one of the core contributors of Fish? Otherwise I don't see why you'd argue in their place. According to the issue they seem perfectly fine with taking the maintenance burden of any patches to support older hardware, and they are even assisting the issue author to troubleshoot, so not sure what the problem is here?
You never know when some customer will put you in front of a vt220 and ask you to solve some arcane issue, and I sure am happy that at least some people care about helping others even if they don't have that specific hardware themselves.
> "We"? Are you one of the core contributors of Fish? Otherwise I don't see why you'd argue in their place.
It's not about arguing in their place. It's about thinking where our collective (includes the mentioned developers, me, and you as well) wants to take its technology. What afffects you, affects me and vice versa. We're not as seperate as you make out.
I’ve been in the field for 25 years, including work inside telco COs and large data centers, and as far as I know I’ve never been in the same room as a VT220. I doubt that many of my more junior coworkers have even heard of one.
I know what they are and how you might still use one today, but they’re extremely rare outside maybe a couple of very narrow niches.
When I was in college in the mid 90's, VT220's were still common on some parts of campus. A few years later, I had a job at a mostly DEC shop. They had a few terminals here and there, connected to Alpha Servers and a couple of old VAXes.
I haven't seen one in the wild in a little over 20 years...
That’s certainly possible, but if so it wasn’t something I had personal contact with enough to register that it happened. And I definitely knew what those terminals were, so I’m pretty certain I would have noticed that “oh, hey! A real VT220!”
I appreciate your comment, although I'm honestly surprised that fish maintainers are willing to put any effort into this, considering that fish is a "modern" shell which doesn't take backwards compatibility very seriously and isn't afraid of breaking with the traditional way of doing shell stuff.
Thanks! I don't know if I agree with your "doesn't take backwards compatibility very seriously" point specifically, although they do indeed try to refresh the shell UX a bit. Specifically from their design document[0], there is no mentions of backwards compatibility (except in connection to configurations), but they do mention that one of the goals is to follow posix syntax as much as possible, so seems they do have some care about backwards compatibility.
And lastly, "breaking with the traditional way of doing shell stuff" doesn't necessarily mean "doesn't work on old hardware", just means that the shell UX will/can be different, but similar.
> which doesn't take backwards compatibility very seriously
I go out of my way to make sure fish still compiles on ancient versions of operating systems (with the most recent compiler you can get on them) and still remains functional in the kernel console (no X), and others on the team go to even further extremes. We’ve argued for weeks over changing the names of variables that might break older fish scripts, even though fish isn’t really a non-interactive scripting language.
I think it is due to personal nostalgia and technical curiosity. Solving these kind of issues are more of a hobby contrasted to real work that needs to be done on project. Thus sparking more joy and engagement.
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.