Fish is not operational on a VT220 terminal (2015)
github.com
github.com
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.
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.
- 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.
One reason against would be I guess the VT200 is a lot less pleasant to look at than an average display device one has laying around in 2020?
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.
And there's the software too: the buggy Hyperterm (except the private edition), Procomm, Minicom... These days I use Knossos' dterm ( http://www.knossos.net.nz/resources/free-software/dterm/ ).
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.
Whoa.
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.
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.
Notable deviations from the default curses db:
- Using a PC keyboard instead of the DEC keyboard (different codes for F-keys)
- Fixes for status line
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.
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.
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?
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.
`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.
I used such a cable for testing a silly terminal library with some vintage terminals: https://www.neilvandyke.org/racket/charterm/
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.
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 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?
Why is it using xterm codes indiscriminately?
According to https://github.com/fish-shell/fish-shell/blob/a1fd9e1b851bd8... it knows what the defaults are, so it is obvious that the behaviour is overridden elsewhere.
So yeah. It's a bug.
I'm saying that using antiquated hardware for interfacing with modern systems violates the principle of least astonishment for me.
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.
https://github.com/fish-shell/fish-shell/issues/3740
> 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.
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.
You've linked to the fixed version - the linked issue is about five years old, and back then it didn't have those.
It will motivate me to de-invest in a project if I see it more than once, e.g. Chromium and Firefox.
However, after scouring the entire thread, I didn't notice anything like that in the linked thread?
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.
i think the missing piece is grassroots support for individual users by the technically literate elite.
I don't see anything wrong with what he posted in that thread.
"I have hardware from 40 years ago, your software doesn't work, please fix?"
If I would have seen that I might have replied: "Patches welcome" :-)
Rude, entitled users is definitely a problem maintainers have to face. Here's a better example:
But I don't think that this thread was such a case.
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.
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.
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. http://www.os2museum.com/wp/why-does-windows-really-use-back...
2. https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:I...
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.
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.
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.
A lot of pain in systems comes from unbound backwards compatibility
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.
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.
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.
You’re going to have to qualify that statement.
Yeah with utmost certainty not gonna happen for the vast, vast majority of jobs.
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.
> 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.
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.
The greater sins I see today are assuming line length and assuming background colour.