10 ms·

Fish is not operational on a VT220 terminal (2015)

226 points by harporoeder 6y ago

raverbashing 6y ago
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
- capableweb 6y ago
  "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.
  - scaladev 6y ago
    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.
    - aequitas 6y ago
      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.
    - capableweb 6y ago
      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. - [0] https://fishshell.com/docs/current/design.html https://fishshell.com/docs/current/design.html
    - ComputerGuru 6y ago
      > 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. You’re going to have to qualify that statement.
  - raverbashing 6y ago
    It's a generic comment, I'm not talking about fish only
  - bauerd 6y ago
    >You never know when some customer will put you in front of a vt220 Yeah with utmost certainty not gonna happen for the vast, vast majority of jobs.
    - moonbug 6y ago
      oh you sweet summer child.
      - kstrauser 6y ago
        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.
        Aloha 6y ago
        I would bet that you have been in front of a VT220, or VT320, or a real terminal that could emulate one of them. Nortel Meridians for example (yay, ld21) use a serial terminal, usually read DEC, usually a VT220 or 320. But there are WYSE (and others too) terminals too, which usually can emulate a 220, and so on.
        kstrauser 6y ago
        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!”
        icedchai 6y ago
        Yep, they are very uncommon these days. 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...
  - dmos62 6y ago
    > "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.
- rutthenut 6y ago
  I'd argue that supporting a known legacy standard makes more sense - it isn't exactly 'unbounded', it is compatibility support.
- senko 6y ago
  If you read the issue comments, you can see this: > 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.
  - raverbashing 6y ago
    Thanks for pointing this out, I had read this and really is an issue with fish
    - masklinn 6y ago
      In fact the somewhat more useful issue is https://github.com/fish-shell/fish-shell/issues/3740 https://github.com/fish-shell/fish-shell/issues/3740 where this problem ended up finally being understood / diagnosed (it's also linked at the very end of TFA).
    - irateswami 6y ago
      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.
- bayindirh 6y ago
  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.
- mhh__ 6y ago
  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.
- GekkePrutser 6y ago
  That's what termcap/terminfo is for. 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.
  - kps 6y ago
    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.
grenoire 6y ago
Author of the issue is Drew DeVault, by the way, the author of sr.ht and many other cool things https://git.sr.ht/~sircmpwn https://git.sr.ht/~sircmpwn.
- __s 6y ago
  He also wrote a blog post about using a VT220: https://drewdevault.com/2016/03/22/Integrating-a-VT220-into-my-life.html https://drewdevault.com/2016/03/22/Integrating-a-VT220-into-...
opless 6y ago
I'd say that this violates the "Principle of least astonishment".
- phoe-krk 6y ago
  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.
  - dirkt 6y ago
    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).
    - phoe-krk 6y ago
      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.
      - opless 6y ago
        So you agree, sending non-vt220 codes to a vt220 device is unacceptable? :)
        phoe-krk 6y ago
        Yes, sending commands to a device that is not capable of accepting these commands is a bug. Good now? :D
    - moonbug 6y ago
      That's not the root cause.
sagichmal 6y ago
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.
- blueflow 6y ago
  Yes, thats how ddevault is.
- forgotmypw17 6y ago
  I see a lot of this in the software world, from both reporters and maintainers. 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?
- tester756 6y ago
  where is he actually "rude" or acts like "and an air of expectation, as if the maintainers owe him a solution"?
  - myspy 6y ago
    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.
    - forgotmypw17 6y ago
      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.
deleted 6y ago
[deleted]
blueflow 6y ago
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.
- MartijnBraam 6y ago
  VT520 here too, can you share your custom terminfo?
  - blueflow 6y ago
    https://git.lain.church/nero/etc/src/branch/master/terminfo/vt520.info https://git.lain.church/nero/etc/src/branch/master/terminfo/... 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
    - GekkePrutser 6y ago
      Thanks for that!! I also use a PC keyboard with my 520.
- gambiting 6y ago
  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.
dboreham 6y ago
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.
- the_only_law 6y ago
  I think there’s a vt220 on eBay right now, I debated snatching it up, but it will probably be gone when I go back to look.
  - dboreham 6y ago
    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..
CapriciousCptl 6y ago
> 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.
- moonbug 6y ago
  Keep reading...
academi 6y ago
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.
- arghwhat 6y ago
  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. http://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/ http://www.os2museum.com/wp/why-does-windows-really-use-back... 2. https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:IBM_Model_F_XT.png https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:I...
marcan_42 6y ago
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.
- kevin_thibedeau 6y ago
  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.
  - ajross 6y ago
    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.
    - kps 6y ago
      Pushing a V8 Streams module to map Unicode to DEC-MCS should be straightforward.
mprovost 6y ago
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.
z3t4 6y ago
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.
neilv 6y ago
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). I used such a cable for testing a silly terminal library with some vintage terminals: https://www.neilvandyke.org/racket/charterm/ 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.
- unilynx 6y ago
  Wasn’t the parallel port male and the 25 pin serial port female ?
- neilv 6y ago
  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.)
ChuckMcM 6y ago
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.
- onedognight 6y ago
  > 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.
  - ChuckMcM 6y ago
    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?

226 points by harporoeder 6y ago

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

capableweb 6y ago
"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.
- scaladev 6y ago
  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.
  - aequitas 6y ago
    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.
  - capableweb 6y ago
    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. - [0] https://fishshell.com/docs/current/design.html https://fishshell.com/docs/current/design.html
  - ComputerGuru 6y ago
    > 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. You’re going to have to qualify that statement.
- raverbashing 6y ago
  It's a generic comment, I'm not talking about fish only
- bauerd 6y ago
  >You never know when some customer will put you in front of a vt220 Yeah with utmost certainty not gonna happen for the vast, vast majority of jobs.
  - moonbug 6y ago
    oh you sweet summer child.
    - kstrauser 6y ago
      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.
      - Aloha 6y ago
        I would bet that you have been in front of a VT220, or VT320, or a real terminal that could emulate one of them. Nortel Meridians for example (yay, ld21) use a serial terminal, usually read DEC, usually a VT220 or 320. But there are WYSE (and others too) terminals too, which usually can emulate a 220, and so on.
        kstrauser 6y ago
        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!”
      - icedchai 6y ago
        Yep, they are very uncommon these days. 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...
- dmos62 6y ago
  > "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.
rutthenut 6y ago
I'd argue that supporting a known legacy standard makes more sense - it isn't exactly 'unbounded', it is compatibility support.
senko 6y ago
If you read the issue comments, you can see this: > 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.
- raverbashing 6y ago
  Thanks for pointing this out, I had read this and really is an issue with fish
  - masklinn 6y ago
    In fact the somewhat more useful issue is https://github.com/fish-shell/fish-shell/issues/3740 https://github.com/fish-shell/fish-shell/issues/3740 where this problem ended up finally being understood / diagnosed (it's also linked at the very end of TFA).
  - irateswami 6y ago
    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.
bayindirh 6y ago
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.
mhh__ 6y ago
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.
GekkePrutser 6y ago
That's what termcap/terminfo is for. 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.
- kps 6y ago
  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.

grenoire 6y ago

Author of the issue is Drew DeVault, by the way, the author of sr.ht and many other cool things https://git.sr.ht/~sircmpwn https://git.sr.ht/~sircmpwn.

__s 6y ago
He also wrote a blog post about using a VT220: https://drewdevault.com/2016/03/22/Integrating-a-VT220-into-my-life.html https://drewdevault.com/2016/03/22/Integrating-a-VT220-into-...

opless 6y ago

I'd say that this violates the "Principle of least astonishment".

phoe-krk 6y ago
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.
- dirkt 6y ago
  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).
  - phoe-krk 6y ago
    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.
    - opless 6y ago
      So you agree, sending non-vt220 codes to a vt220 device is unacceptable? :)
      - phoe-krk 6y ago
        Yes, sending commands to a device that is not capable of accepting these commands is a bug. Good now? :D
  - moonbug 6y ago
    That's not the root cause.

sagichmal 6y ago

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.

blueflow 6y ago
Yes, thats how ddevault is.
forgotmypw17 6y ago
I see a lot of this in the software world, from both reporters and maintainers. 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?
tester756 6y ago
where is he actually "rude" or acts like "and an air of expectation, as if the maintainers owe him a solution"?
- myspy 6y ago
  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.
  - forgotmypw17 6y ago
    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.

deleted 6y ago

[deleted]

blueflow 6y ago

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.

MartijnBraam 6y ago
VT520 here too, can you share your custom terminfo?
- blueflow 6y ago
  https://git.lain.church/nero/etc/src/branch/master/terminfo/vt520.info https://git.lain.church/nero/etc/src/branch/master/terminfo/... 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
  - GekkePrutser 6y ago
    Thanks for that!! I also use a PC keyboard with my 520.
gambiting 6y ago
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.

dboreham 6y ago

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.

the_only_law 6y ago
I think there’s a vt220 on eBay right now, I debated snatching it up, but it will probably be gone when I go back to look.
- dboreham 6y ago
  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..

CapriciousCptl 6y ago

> 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.

moonbug 6y ago
Keep reading...

academi 6y ago

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.

arghwhat 6y ago
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. http://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/ http://www.os2museum.com/wp/why-does-windows-really-use-back... 2. https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:IBM_Model_F_XT.png https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:I...

marcan_42 6y ago

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.

kevin_thibedeau 6y ago
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.
- ajross 6y ago
  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.
  - kps 6y ago
    Pushing a V8 Streams module to map Unicode to DEC-MCS should be straightforward.

mprovost 6y ago

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.

z3t4 6y ago

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.

neilv 6y ago

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). I used such a cable for testing a silly terminal library with some vintage terminals: https://www.neilvandyke.org/racket/charterm/ 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.

unilynx 6y ago
Wasn’t the parallel port male and the 25 pin serial port female ?
neilv 6y ago
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.)

ChuckMcM 6y ago

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.

onedognight 6y ago
> 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.
- ChuckMcM 6y ago
  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?