8 ms·

I could never really understand the enthusiasm. Why are we still dealing with over half a century of cruft? I get that this is a core piece of technology lots o

by 9dev 2y ago

I could never really understand the enthusiasm. Why are we still dealing with over half a century of cruft? I get that this is a core piece of technology lots of stuff is built upon, and I'm not arguing to get rid of the classic terminal emulation altogether. But I wish there was an effort of building a new, modern, textual interface to computers with modern assumptions and integration bindings. We shouldn't need to be concerned with obscure escape sequences to print color; tooling shouldn't need to parse strings to do something useful; and junior developers shouldn't need to waste hours scrolling an obtuse man page until they resort to a half-assed SO response with broken parameters to extract a tar archive. There is more to shells and text interfaces than working within constraints set 50 years ago.

dmd 2y ago
There are tons of efforts like that. https://xkcd.com/927/ https://xkcd.com/927/
hnlmorg 2y ago
The problem is to break away from ANSI escape sequences and the like means also rewriting 50 years of command line tools. Like with the modern web, there’s just too much momentum behind the current design to make it practical to reinvent it from scratch That doesn’t mean that things cannot improve though. It just makes it massively more difficult if you want to retain backwards compatibility. And if you don’t, then people probably won’t adopt it because they won’t be able to get their job done, regardless of how good the UX is. As it happens, I am trying to solve these problems. In part with my alternative shell. To take your SO example, I’ve recently even playing around with integrating ChatGPT to help with hints (on top of automatic man page parsing which already happens). I’m also writing a new terminal emulator that aims to bring interactive widgets (like support for sorting and filling anything that looks like a table). But that term is very much alpha at the moment.
- pjmlp 2y ago
  Only in regards to UNIX CLI tools, computing history is full of other kinds of command line interfaces.
  - hnlmorg 2y ago
    Sure. And aside from Powershell, which itself had to recreate a bunch of common UNIX idioms, which of those other command line interfaces are still in widespread usage? The status quo is ugly but reinventing it is at least an order of magnitude more work than improving upon it.
    - pjmlp 2y ago
      Amiga DOS doesn't seem to go away no matter what. IBM and Unisys mainframes and micros. Smalltalk and Common Lisp REPL environments. Although probably debatable to consider any of them mainstream.
      - hnlmorg 2y ago
        The fact that you opened your rebuttal with DOS basically proves the point I’m making. > Although probably debatable to consider any of them mainstream. The only person debating that point is you. We could be online until the sun rises debating about different command line environments but if AWS (for example) haven’t released an official CLI utility for Amiga DOS then your position is ultimately just an academic one.
        pjmlp 2y ago
        Amiga DOS !== UNIX CLI, and if you don't get why, well so be it, lets worship 1970's printer hardware instead.
        hnlmorg 2y ago
        I'm giving you the benefit of the doubt that you're just mistaken rather than trolling: 1. I never said Amiga DOS was the same as UNIX CLI. In fact I never even compared the two, that was all you 2. I do get why different command line interfaces are different -- I author a significant amount of code towards terminal emulators, shells, command line tools and maintain a hell of a lot of retro systems. So I'm definitely experienced on this subject. In fact I bet I could teach you a thing or two on this topic too ;) But that wasn't the point of what was being discussed. We were talking about the state of the status quo, not how some niche interface that nobody has used for serious work in nearly 30 years compares to the entrenched standard. 3. I never once said the UNIX CLI was peak command line design either. In fact I actually said the exact opposite. What I actually said was that it was dominant. Dominance != well designed 4. ANSI escape sequences, the $TERM env var, and all the other terminal UX stuff that are being discussed here, came about with hardware terminals like the VT-series. Yes, teletypes are part of mainframe history, but they're not relevant to this specific discussion here. Terminal emulators don't emulate a teletype, the POSIX kernel does that. Terminal emulators ostensibly just open a file and emulate how VTs interpreted ANSI escape sequences. This is the same reason why you can have terminal emulators on Windows (like PuTTY, Microsoft Terminal, and my own terminal emulator) despite Windows never having a concept of a PTY. Though, perhaps ironically, Windows now does support an approximation of a PTY. --- My point was very clear: the current status quo sucks but it would be an order of magnitude more work re-implementing everything from scratch and it ultimately wouldn't likely gain adoption anyway because of the momentum behind the current status quo. Microsoft understood this and ended up re-implementing some of the concepts despite literally decades fighting against it. History is littered with examples of sub-par technologies becoming dominant because they work just good enough to maintain any initial momentum they have behind them. And people would sooner use what they're familiar with than learn something entirely new just because it is technically better. And the fact that you keep harping on about Amiga DOS is, frankly, absurd. I love the Amiga, I honestly do. I have one sat next to me right now. But if there was one example in history of a command line interface that sucked more than the Bourne shell, it would be DOS. Mentioning Lisp machines might have earned you a little kudos yet you chose to lead with Amiga DOS.....
- bmitc 2y ago
  > The problem is to break away from ANSI escape sequences and the like means also rewriting 50 years of command line tools. Are we really that reliant on those command line tools? I only use a handful of them, and any time it gets more complicated, I reach for a real programming language to do the scripting. Those tools just do a bunch of string parsing, and the user interfaces are usually incredibly esoteric, inconsistent, and obtuse.
  - yjftsjthsd-h 2y ago
    In a word: Yes. The long tail is very long, and it's not just the bare text tools, it's the bare text tools (including tools that were written 30 years ago and that haven't changed since, and the tools that barely even count as cli tools), and also anything that ever did anything more interesting. You're not just talking about rewriting coreutils, you're also talking about redoing vim and emacs and top and all the *stat programs and tmux and screen and ...
- dooglius 2y ago
  Why can't we make it backward compatible so an interface has each client application say "I support the new interface" if it does? You probably would need to add kernel support to handle the fork/execve case, but I don't think that there is an intrinsic limitation.
  - hnlmorg 2y ago
    fork et al are manage by the shell, not the terminal emulator. And what you're suggesting is exactly what feature flagging in ANSI escape codes achieves. 50 year old teletypes already had way to announce support for new interfaces.
dartos 2y ago
There is an effort, but it’s mostly built on cruft (which libraries like ncurses or the projects at charm.sh try abstracting away) Also, what would we use besides escape sequences? They are about as small as can be for what they do. Terminals deal with streams of bytes. They don’t just download entire views and render them (normally.) This normally works to their advantage. There’s also the ansi standard control sequences, which imo should have more focus on them as opposed to the terminfo db.
- 9dev 2y ago
  > Terminals deal with streams of bytes. But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead? > There’s also the ansi standard control sequences, which imo should have more focus on them as opposed to the terminfo db. Everything in that sentence \033[31;1;4munderlines\033[0m the problem to me: If we didn't need to nest metadata into the byte stream, none of us needed wrestle with escape sequences. And that such a thing like the terminfo db even needs to exist speaks volumes about the lengths we have to go to to accommodate for decades of cruft… Applications should neither be concerned with what color codes the output device can render, nor should the terminal itself have to support hundreds of emulation targets.
  - camgunz 2y ago
    There are libraries and frameworks that abstract this for you: ncurses, bubbletea, etc. At some point, every interface is low-level: GPU geometry is a stream of vertices, a program is a stream of bytes. This isn't some terminal-specific tech problem, it's just kind of how computers are.
    - 9dev 2y ago
      Abstractions are layered a specific way, though. Layering upon something suboptimal will always be limited by the suboptimal layer. Ncurses or bubbletea et all may hide it from you, but they still only paint over the bumpy legacy wall below without being able to really improve on it.
Borg3 2y ago
First, dont like it? Dont use it. No need to cry over it. Second, dont like it? Write something better, do show case and maybe people like it and start using it. Third, not everyone needs to use 100s of MB of memory to render some idiotic emoji along the text using GPU accelerated routines. Those old legacy stuff is lightweight, its everywhere so I can run stuff on platforms that problem existed before you were even born. I myself love CLI. Its reliable, easy to use, fast!! interface. I cant really imagine a computer without CLI.. Its like? WTF? :)
- vacuity 2y ago
  While no one is entitled to other's time for free software, your comment is needlessly dismissive and discouraging. People can have legitimate complaints and try to rally others to change the status quo. No one is encroaching on your right to use the software you choose. You also seem to have preconceived notions of what GP envisions. You can stick to your own thing, but don't stifle the creativity and fervor of others.
  - Borg3 2y ago
    But I dont see it as being creative. He is just complaining, not even giving any new ideas.
- bmitc 2y ago
  > First, dont like it? Dont use it. No need to cry over it. > Second, dont like it? Write something better, do show case and maybe people like it and start using it. Anytime I use a graphical tool, command line afficionados effectively reel in disgust. So I'd say that it's those people who need to get over that some people don't like typing in a terminal to do their work and want to work differently and often more efficiently.
  - Borg3 2y ago
    GUI is more efficient? Joke.. JOKE :) GUI have it uses, for example data presentation and visualization. Oh I have nice tools here too. But data manipulation and query? CLI only or mixed where you query in CLI, got graph output.
pjmlp 2y ago
Me neither, having started to program when this is all we had, and graphical displays costed a fortune, I really don't get this desire to live in the past.
fipar 2y ago
While I don't disagree with your sentiment I have a few comments: "Why are we still dealing with over half a century of cruft?". IMHO that's because we have software running that's over half a century, with organizations depending on it, and so it needs to continue running. This means we need to continue providing that software with the environment it expects. For over a decade, a significant part of my recurring revenue came from helping companies make sure their ancient software would continue to run on newer machines (and they only got newer machines because it was no longer possible to keep the older hardware running). And this was on PC hardware, from my short experience in finance, I reckon there's a bunch of 390 software still running emulated on modern z/OS machines. "tooling shouldn't need to parse strings to do something useful" The thing is tooling either needs to process some binary format, which is more efficient but also more obscure, or to parse strings. All the tooling that deals with json, yaml, etc is still parsing strings, and I prefer that to a binary format in most cases. I know a defined format like yaml is simpler to parse than free-form text, but it maintains some of the same constraints (notably the need to escape things). Your comment about escape sequences to print color is very relevant. I feel two concurrent yet opposite feelings here: I get all warm inside from nostalgia since I spent what probably was an unhealthy amount of time learning about ansi sequences back in the day of BBSs, and I also despise that completely and would love to be able to have color on a textual computer interface without the need for that. I believe that's possible, but most likely, because the effort to achieve that is significantly bigger than the effort to keep hacking what we have, is why we don't have a new textual computer interface. Challenges I can imagine: while I despise dealing with escape sequences (because I invariable got them wrong the first time, always), it's either something like that, or a side channel to convey formatting information. Or we move to html altogether. I guess this is the approach of text-intensive applications based on web frameworks (like I suppose most modern editors). There's the option emacs takes, which is to just have the text be plain text (whatever that means, really, we like to think it's a simple format because we can cat it and wysiwyg, but for the computer, it's all a bunch of bytes anyway) and use modes to alter how the editor shows you that text. As an emacs user I'm biased to think that's a better approach than html or a side channel, but I don't see that becoming the norm in the short term. "and junior developers shouldn't need to waste hours scrolling an obtuse man page until they resort to a half-assed SO response with broken parameters to extract a tar archive" Now that is one hill I'm willing to die on: if someone can't figure out how to extract a tar archive just from looking at the synopsis on the man page and scrolling through the options, unless the archive was maliciously named to hide the fact that it's gzipped or something, I think that person would be a pre-junior developer and still have a way to go to become junior. Note I'm not saying all developers must use the command line: if you prefer to open archives with a GUI tool that's fine, but if for whatever reason you need to open it from the command line and you can't figure that out from the man page, I think it says more about them than about tar. Perhaps it's just a poor choice of example, as I agree there are very poor man pages out there, but for the basic use cases, I think tar is as understandable as it can get. "There is more to shells and text interfaces than working within constraints set 50 years ago." Completely agree, which is why I often use the emacs shell, which is not a POSIX shell, and you know what? I don't care. I go to zsh when I need that, but often times, the emacs shell gets me what I need with less friction. And I'm sure the same would be possible with other shells. I wish we had more new shells that attempt to keep what seems useful about 'the old shells' but discards all that's not strictly needed and adds new, useful features.
Workaccount2 2y ago
I'm bewildered that the "user friendly" flavors of linux still use ancient terminals. If the fact that these distros still lean heavily on terminal use wasn't bad enough, you also need to have a computer intuition from 1985 to feel comfortable using it. At least capitulate to ctrl+v and ctrl+c.
- canthonytucci 2y ago
  Would Ctrl-c work conditionally based on if there is a foreground process? What if I want to paste in to the process? The command key on macOS really comes in handy here. The “windows” key on most Linux desktop environments I have used is usually pretty under-utilized, perhaps there’s a case to be made that super-v should default to paste.
  - dontdieych 2y ago
    <S-Ins>
- yjftsjthsd-h 2y ago
  > I'm bewildered that the "user friendly" flavors of linux still use ancient terminals. Do they? I was given to believe that you can use modern Ubuntu/Fedora/OpenSUSE without needing to open a terminal. > If the fact that these distros still lean heavily on terminal use wasn't bad enough, you also need to have a computer intuition from 1985 to feel comfortable using it. At least capitulate to ctrl+v and ctrl+c. Okay, let's say we're going to break backwards-compatibility; how should the user kill the running program, and how should they input character literals, and how are we going to implement your change?
  - Workaccount2 2y ago
    Just to get it out of the way - Linux is great if you are a grandma or linux junkie. It sucks for everyone in between, especially for those who come from Windows or MacOS. -- This is the fundamental problem with the terminal, it is extremely powerful when you are intimately familiar with using it. And it's unsurprising that people building distros and maintaining linux fall into that camp. What they are completely blind to is how incredibly user hostile the environment for people from a GUI complete background. What is the first thing every mainstream Unix based OS does? They take the terminal and hide it. They make menus and menus of GUI elements that cover 80-90% of the things you would typically use the terminal for aside from the 5% of ultra power users. My gripe is primarily that Linux is _desparetly_ needed now more than ever as an escape from windows. But the people who are working on linux distros are so lost in their egos that they are arrogantly trapped in this idea that everyone needs to be driving stick shift in 2024 because look at how much more control you have compared to an automatic, if that analogy makes sense.
orangecat 2y ago
tooling shouldn't need to parse strings to do something useful; and junior developers shouldn't need to waste hours scrolling an obtuse man page until they resort to a half-assed SO response Absolutely. Glad we fixed all that with CSS...
- 9dev 2y ago
  Could you share what you mean by that? I suppose it was sarcasm, but I didn’t get the point.
  - em-bee 2y ago
    CSS doesn't fix junior developers [wasting] hours scrolling an obtuse man page until they resort to a half-assed SO response
  - orangecat 2y ago
    Ha sorry, that was probably overly snarky. I was thinking of CSS's multitude of string-valued properties that effectively have their own DSLs, ranging from the simple "5px 10px 0px 10px" for padding/margins to much more complicated expressions for gradients and animations. And it's all stringly-typed so (without additional linters) you don't get told when you format values incorrectly or set mutually exclusive properties. But there are also lots of advantages in terms of flexibility and ease of use (the "API" is just "style.foo = bar"), and that's led to CSS being ubiquitous and extremely successful. I think this applies to some of your complaints about terminals as well. Yes escape sequences are ugly, but it means I can just emit the appropriate bytes from any program written in any language rather than figuring out what library I need to import to generate a correctly formatted structured message, and operating on the byte stream level lets it transparently work across remote connections. I'm all for experimenting with new approaches, but we shouldn't lose sight of the existing benefits.
mandibles 2y ago
While we're at it, can we get rid of staggered keyboards? We don't need to accommodate mechanical linkages from the bottom rows any longer, yet here we are. As other commenters have pointed out, once conventions and standards have been adopted, there is almost no way of dislodging them. It's a coordination problem. New standards and approaches usually need to be at least a 10x improvement over the status quo in order to be adopted organically. The same story applies to all areas of human endeavor.
- 9dev 2y ago
  Im not so sure. We have HTTP3 now, which is binary. We use different image formats than we used to, and switched from horses to cars, too. Why shouldn’t we be able to innovate in this space? Building new walls doesn’t automatically imply tearing old ones down.
  - wang_li 2y ago
    > Building new walls doesn’t automatically imply tearing old ones down. But often in this space they seem to want to do that anyway. I can only imagine that they are attempting to force people to adopt their pet project. There's literally no reason a pair of sequences can't be specified that allows clients to query support for advanced terminal mode and get a response. After the client and the terminal have agreed on advanced mode, switch to a byte stream/command blocks/whatever which allow rich text, graphics, sound, access to UI devices, etc. Whan you're done you've recreated X11, but they can do whatever they like I guess. There's no need to fuck up terminfo along the way though.
ykonstant 2y ago
Arcan is one such effort, but I am not sure what state the project is in.
bashinator 2y ago
In my opinion, the Lindy Effect[0] makes a lot of sense in scenarios like this. Personally, I love the fact that the slower evolution of command-line tools gives my personal skillset a longer shelf life. I can add additional capabilities without having to constantly re-learn how to do established work. [0] https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
PurpleRamen 2y ago
> But I wish there was an effort of building a new, modern, textual interface to computers with modern assumptions and integration bindings. Would it be different from a web-browser? Isn't the webstack already the modern textual interface everyone is using? I mean that's also the direction they all are walking to, with adding images to terminals, having more complex layout with TUIs. I think I remember some TUI-toolkit which even used a limited CSS for describing their interface. And there are some terminals and alternatives which are build with NodeJS and webstack IIRC. So would it make more sense to find some proper standards for webstack-based cli-interfaces?
- 9dev 2y ago
  > Isn't the webstack already the modern textual interface everyone is using? I would argue that the web stack is really more of a virtual machine, or OS-agnostic application runtime, but it is not a textual interface per se (albeit it certainly can be used that way). On the other hand, I'm looking for solid primitives to make applications talk to each other, but with structured data instead of plain text open to liberal interpretation; for terminals that don't emulate a teletype device, but make use of modern operating systems. Think of what we had before systemd—the wild west of shell scripts, layers upon layers of arcane compatibility hacks—and what we have now—a standardised, documented, structured, system management interface that works the same way everywhere (please don't lets discuss systemd here, it's just an analogy). So rather than trying to paint NodeJS-lipstick on the TTY-pig, I'd like to see a new kind of terminal protocol that solves the UX issues of old.
  - PurpleRamen 2y ago
    > I'm looking for solid primitives to make applications talk to each other, but with structured data instead of plain text open to liberal interpretation JSON exists. YAML exists. XML exists. The lack of proper exchange-formats is not a problem. The lack of tooling is the problem. > Think of what we had before systemd—the wild west of shell scripts Liberty. And this gives you an answer why terminals, shells and cli in general remain this way. People have the liberty to do what they need, and they have the liberty to go as simple or complex as they want. And this works very well. Don't forget that not all output is structured. So unless you have someone creating a whole new set of tools and environment which can compete with the established solutions, and beat them on ALL aspects, and is still compatible...until then people will not support it. I mean, there are more than enough alternatives who are barely popular for one reason or another. Speaks for itself. > I'd like to see a new kind of terminal protocol that solves the UX issues of old. Which are the issues? Is there some solid documentation on them?
revscat 2y ago
> There is more to shells and text interfaces than working within constraints set 50 years ago. Of course. With some minor changes, you could make the same argument many, many technologies we use every day, from IPv4 to SQL to C. Then there is the old saw -- likely apocryphal -- about how railroads are the width they are because they evolved from standards around Roman roads. Even if it is a fairy tale, the moral of that story strikes true: existing tools are built on top of old ones, because it was better to have a standard then even if we may know better now.
- 9dev 2y ago
  IPv4 is a great example, because the transition to IPv6, albeit slow, is happening. And that is an all-renewed protocol with a lot of previously impossible, awesome features. There is a way to do this right.
  - NackerHughes 2y ago
    It’s also exponentially more complicated, has addresses that are a mile long and impossible to memorise, and has enabled such marvels as a toaster that outright refuses to make you breakfast unless it’s connected to the internet with an active subscription and all the telemetry that comes with it. Truly a great example of a way to do things right.
deleted 2y ago
[deleted]
theamk 2y ago
Is there? Lets put a few reasonable requirements down: - Self-sufficient commands that you can store in history, put on wiki page, put inside a script file, Slack to your friends, store in configuration, etc... - Variety of execution methods: local computer, remote via ssh, jupyter-like notebook, remote via something else (like AWS SSM), CI runner, ssh which launches SSM session which connects over serial port, cron-like periodic schedulers, starting commands in your Go program etc... Every method should be supported automatically with no effort from developer. - Output could be interactive (possibly with some reprocessing like tmux/screen does) or stored (like CI/cron execution). It is possible to parse output to get relevant details. Even if you start from scratch, what can you design to fit this pattern? You'll get something very close to existing state - applications that take command lines, character-based input/output streams with some sort of formatting sequences. Sure, if I could design from scratch I'd standardize on _one_ TERM, make escape sequences easier to parse (longer and common start/end chars), fix extended keys/numpad mess, redesign the CLI defaults of the few tools, create common command-line completion interfaces... but the overall idea will be the same. (And if you don't care about the three requirements above, then go with HTML or native UI! There are tons of them and they are well supported. But I don't see the point of retrofitting HTML-like functionality to exiting terminals)
- 9dev 2y ago
  There definitely are more options than applications reading and writing character streams, you’re just not even considering them because you’re too entrenched in the environment you’re familiar with. Take Powershell for example; the syntax may be horrible, but the way it passes structured data is truly different and way ahead of classic UNIX shells. The design space is huge; just dismissing any possible improvements before even sitting down and thinking properly is frankly not a good strategy.
  - theamk 2y ago
    If the design space is so huge, how about giving some examples, instead of insulting people who disagree with you? Surely you'll be able to do so, while satisfying the requirements I listed? Because Powershell doesn't satisfy them. You are not going to save Powershell object stream yo CI output or provisioner logs. You are not going to send objects over SSH, or over web console, or over BMC-emulated serial port. In all of those cases it's going to be good old stream of characters, with the occasional control sequence from more advanced programs. You can have whatever rich datatypes inside your application (powrshell isn't the first, I remember reading about LISP shells back in 2000's), but at some moment you have to talk with other systems, and that's when you will have to switch to character streams. (that said, the current escape sequences could use lots of improvement. That's not going to change fundamental concept though)
Ferret7446 2y ago
Chesterton's Fence is in full effect here. Quite a few people have tried to do exactly what you wish. They haven't really succeeded, obviously.

by 9dev 2y ago

dmd 2y ago

There are tons of efforts like that. https://xkcd.com/927/ https://xkcd.com/927/

hnlmorg 2y ago

The problem is to break away from ANSI escape sequences and the like means also rewriting 50 years of command line tools. Like with the modern web, there’s just too much momentum behind the current design to make it practical to reinvent it from scratch That doesn’t mean that things cannot improve though. It just makes it massively more difficult if you want to retain backwards compatibility. And if you don’t, then people probably won’t adopt it because they won’t be able to get their job done, regardless of how good the UX is. As it happens, I am trying to solve these problems. In part with my alternative shell. To take your SO example, I’ve recently even playing around with integrating ChatGPT to help with hints (on top of automatic man page parsing which already happens). I’m also writing a new terminal emulator that aims to bring interactive widgets (like support for sorting and filling anything that looks like a table). But that term is very much alpha at the moment.

pjmlp 2y ago
Only in regards to UNIX CLI tools, computing history is full of other kinds of command line interfaces.
- hnlmorg 2y ago
  Sure. And aside from Powershell, which itself had to recreate a bunch of common UNIX idioms, which of those other command line interfaces are still in widespread usage? The status quo is ugly but reinventing it is at least an order of magnitude more work than improving upon it.
  - pjmlp 2y ago
    Amiga DOS doesn't seem to go away no matter what. IBM and Unisys mainframes and micros. Smalltalk and Common Lisp REPL environments. Although probably debatable to consider any of them mainstream.
    - hnlmorg 2y ago
      The fact that you opened your rebuttal with DOS basically proves the point I’m making. > Although probably debatable to consider any of them mainstream. The only person debating that point is you. We could be online until the sun rises debating about different command line environments but if AWS (for example) haven’t released an official CLI utility for Amiga DOS then your position is ultimately just an academic one.
      - pjmlp 2y ago
        Amiga DOS !== UNIX CLI, and if you don't get why, well so be it, lets worship 1970's printer hardware instead.
        hnlmorg 2y ago
        I'm giving you the benefit of the doubt that you're just mistaken rather than trolling: 1. I never said Amiga DOS was the same as UNIX CLI. In fact I never even compared the two, that was all you 2. I do get why different command line interfaces are different -- I author a significant amount of code towards terminal emulators, shells, command line tools and maintain a hell of a lot of retro systems. So I'm definitely experienced on this subject. In fact I bet I could teach you a thing or two on this topic too ;) But that wasn't the point of what was being discussed. We were talking about the state of the status quo, not how some niche interface that nobody has used for serious work in nearly 30 years compares to the entrenched standard. 3. I never once said the UNIX CLI was peak command line design either. In fact I actually said the exact opposite. What I actually said was that it was dominant. Dominance != well designed 4. ANSI escape sequences, the $TERM env var, and all the other terminal UX stuff that are being discussed here, came about with hardware terminals like the VT-series. Yes, teletypes are part of mainframe history, but they're not relevant to this specific discussion here. Terminal emulators don't emulate a teletype, the POSIX kernel does that. Terminal emulators ostensibly just open a file and emulate how VTs interpreted ANSI escape sequences. This is the same reason why you can have terminal emulators on Windows (like PuTTY, Microsoft Terminal, and my own terminal emulator) despite Windows never having a concept of a PTY. Though, perhaps ironically, Windows now does support an approximation of a PTY. --- My point was very clear: the current status quo sucks but it would be an order of magnitude more work re-implementing everything from scratch and it ultimately wouldn't likely gain adoption anyway because of the momentum behind the current status quo. Microsoft understood this and ended up re-implementing some of the concepts despite literally decades fighting against it. History is littered with examples of sub-par technologies becoming dominant because they work just good enough to maintain any initial momentum they have behind them. And people would sooner use what they're familiar with than learn something entirely new just because it is technically better. And the fact that you keep harping on about Amiga DOS is, frankly, absurd. I love the Amiga, I honestly do. I have one sat next to me right now. But if there was one example in history of a command line interface that sucked more than the Bourne shell, it would be DOS. Mentioning Lisp machines might have earned you a little kudos yet you chose to lead with Amiga DOS.....
bmitc 2y ago
> The problem is to break away from ANSI escape sequences and the like means also rewriting 50 years of command line tools. Are we really that reliant on those command line tools? I only use a handful of them, and any time it gets more complicated, I reach for a real programming language to do the scripting. Those tools just do a bunch of string parsing, and the user interfaces are usually incredibly esoteric, inconsistent, and obtuse.
- yjftsjthsd-h 2y ago
  In a word: Yes. The long tail is very long, and it's not just the bare text tools, it's the bare text tools (including tools that were written 30 years ago and that haven't changed since, and the tools that barely even count as cli tools), and also anything that ever did anything more interesting. You're not just talking about rewriting coreutils, you're also talking about redoing vim and emacs and top and all the *stat programs and tmux and screen and ...
dooglius 2y ago
Why can't we make it backward compatible so an interface has each client application say "I support the new interface" if it does? You probably would need to add kernel support to handle the fork/execve case, but I don't think that there is an intrinsic limitation.
- hnlmorg 2y ago
  fork et al are manage by the shell, not the terminal emulator. And what you're suggesting is exactly what feature flagging in ANSI escape codes achieves. 50 year old teletypes already had way to announce support for new interfaces.

dartos 2y ago

There is an effort, but it’s mostly built on cruft (which libraries like ncurses or the projects at charm.sh try abstracting away) Also, what would we use besides escape sequences? They are about as small as can be for what they do. Terminals deal with streams of bytes. They don’t just download entire views and render them (normally.) This normally works to their advantage. There’s also the ansi standard control sequences, which imo should have more focus on them as opposed to the terminfo db.

9dev 2y ago
> Terminals deal with streams of bytes. But is this a fundamental constraint, or something we can challenge? Is there any good reason why terminals can't deal with structured data instead? > There’s also the ansi standard control sequences, which imo should have more focus on them as opposed to the terminfo db. Everything in that sentence \033[31;1;4munderlines\033[0m the problem to me: If we didn't need to nest metadata into the byte stream, none of us needed wrestle with escape sequences. And that such a thing like the terminfo db even needs to exist speaks volumes about the lengths we have to go to to accommodate for decades of cruft… Applications should neither be concerned with what color codes the output device can render, nor should the terminal itself have to support hundreds of emulation targets.
- camgunz 2y ago
  There are libraries and frameworks that abstract this for you: ncurses, bubbletea, etc. At some point, every interface is low-level: GPU geometry is a stream of vertices, a program is a stream of bytes. This isn't some terminal-specific tech problem, it's just kind of how computers are.
  - 9dev 2y ago
    Abstractions are layered a specific way, though. Layering upon something suboptimal will always be limited by the suboptimal layer. Ncurses or bubbletea et all may hide it from you, but they still only paint over the bumpy legacy wall below without being able to really improve on it.

Borg3 2y ago

First, dont like it? Dont use it. No need to cry over it. Second, dont like it? Write something better, do show case and maybe people like it and start using it. Third, not everyone needs to use 100s of MB of memory to render some idiotic emoji along the text using GPU accelerated routines. Those old legacy stuff is lightweight, its everywhere so I can run stuff on platforms that problem existed before you were even born. I myself love CLI. Its reliable, easy to use, fast!! interface. I cant really imagine a computer without CLI.. Its like? WTF? :)

vacuity 2y ago
While no one is entitled to other's time for free software, your comment is needlessly dismissive and discouraging. People can have legitimate complaints and try to rally others to change the status quo. No one is encroaching on your right to use the software you choose. You also seem to have preconceived notions of what GP envisions. You can stick to your own thing, but don't stifle the creativity and fervor of others.
- Borg3 2y ago
  But I dont see it as being creative. He is just complaining, not even giving any new ideas.
bmitc 2y ago
> First, dont like it? Dont use it. No need to cry over it. > Second, dont like it? Write something better, do show case and maybe people like it and start using it. Anytime I use a graphical tool, command line afficionados effectively reel in disgust. So I'd say that it's those people who need to get over that some people don't like typing in a terminal to do their work and want to work differently and often more efficiently.
- Borg3 2y ago
  GUI is more efficient? Joke.. JOKE :) GUI have it uses, for example data presentation and visualization. Oh I have nice tools here too. But data manipulation and query? CLI only or mixed where you query in CLI, got graph output.

pjmlp 2y ago

Me neither, having started to program when this is all we had, and graphical displays costed a fortune, I really don't get this desire to live in the past.

fipar 2y ago

While I don't disagree with your sentiment I have a few comments: "Why are we still dealing with over half a century of cruft?". IMHO that's because we have software running that's over half a century, with organizations depending on it, and so it needs to continue running. This means we need to continue providing that software with the environment it expects. For over a decade, a significant part of my recurring revenue came from helping companies make sure their ancient software would continue to run on newer machines (and they only got newer machines because it was no longer possible to keep the older hardware running). And this was on PC hardware, from my short experience in finance, I reckon there's a bunch of 390 software still running emulated on modern z/OS machines. "tooling shouldn't need to parse strings to do something useful" The thing is tooling either needs to process some binary format, which is more efficient but also more obscure, or to parse strings. All the tooling that deals with json, yaml, etc is still parsing strings, and I prefer that to a binary format in most cases. I know a defined format like yaml is simpler to parse than free-form text, but it maintains some of the same constraints (notably the need to escape things). Your comment about escape sequences to print color is very relevant. I feel two concurrent yet opposite feelings here: I get all warm inside from nostalgia since I spent what probably was an unhealthy amount of time learning about ansi sequences back in the day of BBSs, and I also despise that completely and would love to be able to have color on a textual computer interface without the need for that. I believe that's possible, but most likely, because the effort to achieve that is significantly bigger than the effort to keep hacking what we have, is why we don't have a new textual computer interface. Challenges I can imagine: while I despise dealing with escape sequences (because I invariable got them wrong the first time, always), it's either something like that, or a side channel to convey formatting information. Or we move to html altogether. I guess this is the approach of text-intensive applications based on web frameworks (like I suppose most modern editors). There's the option emacs takes, which is to just have the text be plain text (whatever that means, really, we like to think it's a simple format because we can cat it and wysiwyg, but for the computer, it's all a bunch of bytes anyway) and use modes to alter how the editor shows you that text. As an emacs user I'm biased to think that's a better approach than html or a side channel, but I don't see that becoming the norm in the short term. "and junior developers shouldn't need to waste hours scrolling an obtuse man page until they resort to a half-assed SO response with broken parameters to extract a tar archive" Now that is one hill I'm willing to die on: if someone can't figure out how to extract a tar archive just from looking at the synopsis on the man page and scrolling through the options, unless the archive was maliciously named to hide the fact that it's gzipped or something, I think that person would be a pre-junior developer and still have a way to go to become junior. Note I'm not saying all developers must use the command line: if you prefer to open archives with a GUI tool that's fine, but if for whatever reason you need to open it from the command line and you can't figure that out from the man page, I think it says more about them than about tar. Perhaps it's just a poor choice of example, as I agree there are very poor man pages out there, but for the basic use cases, I think tar is as understandable as it can get. "There is more to shells and text interfaces than working within constraints set 50 years ago." Completely agree, which is why I often use the emacs shell, which is not a POSIX shell, and you know what? I don't care. I go to zsh when I need that, but often times, the emacs shell gets me what I need with less friction. And I'm sure the same would be possible with other shells. I wish we had more new shells that attempt to keep what seems useful about 'the old shells' but discards all that's not strictly needed and adds new, useful features.

Workaccount2 2y ago

I'm bewildered that the "user friendly" flavors of linux still use ancient terminals. If the fact that these distros still lean heavily on terminal use wasn't bad enough, you also need to have a computer intuition from 1985 to feel comfortable using it. At least capitulate to ctrl+v and ctrl+c.

canthonytucci 2y ago
Would Ctrl-c work conditionally based on if there is a foreground process? What if I want to paste in to the process? The command key on macOS really comes in handy here. The “windows” key on most Linux desktop environments I have used is usually pretty under-utilized, perhaps there’s a case to be made that super-v should default to paste.
- dontdieych 2y ago
  <S-Ins>
yjftsjthsd-h 2y ago
> I'm bewildered that the "user friendly" flavors of linux still use ancient terminals. Do they? I was given to believe that you can use modern Ubuntu/Fedora/OpenSUSE without needing to open a terminal. > If the fact that these distros still lean heavily on terminal use wasn't bad enough, you also need to have a computer intuition from 1985 to feel comfortable using it. At least capitulate to ctrl+v and ctrl+c. Okay, let's say we're going to break backwards-compatibility; how should the user kill the running program, and how should they input character literals, and how are we going to implement your change?
- Workaccount2 2y ago
  Just to get it out of the way - Linux is great if you are a grandma or linux junkie. It sucks for everyone in between, especially for those who come from Windows or MacOS. -- This is the fundamental problem with the terminal, it is extremely powerful when you are intimately familiar with using it. And it's unsurprising that people building distros and maintaining linux fall into that camp. What they are completely blind to is how incredibly user hostile the environment for people from a GUI complete background. What is the first thing every mainstream Unix based OS does? They take the terminal and hide it. They make menus and menus of GUI elements that cover 80-90% of the things you would typically use the terminal for aside from the 5% of ultra power users. My gripe is primarily that Linux is _desparetly_ needed now more than ever as an escape from windows. But the people who are working on linux distros are so lost in their egos that they are arrogantly trapped in this idea that everyone needs to be driving stick shift in 2024 because look at how much more control you have compared to an automatic, if that analogy makes sense.

orangecat 2y ago

tooling shouldn't need to parse strings to do something useful; and junior developers shouldn't need to waste hours scrolling an obtuse man page until they resort to a half-assed SO response Absolutely. Glad we fixed all that with CSS...

9dev 2y ago
Could you share what you mean by that? I suppose it was sarcasm, but I didn’t get the point.
- em-bee 2y ago
  CSS doesn't fix junior developers [wasting] hours scrolling an obtuse man page until they resort to a half-assed SO response
- orangecat 2y ago
  Ha sorry, that was probably overly snarky. I was thinking of CSS's multitude of string-valued properties that effectively have their own DSLs, ranging from the simple "5px 10px 0px 10px" for padding/margins to much more complicated expressions for gradients and animations. And it's all stringly-typed so (without additional linters) you don't get told when you format values incorrectly or set mutually exclusive properties. But there are also lots of advantages in terms of flexibility and ease of use (the "API" is just "style.foo = bar"), and that's led to CSS being ubiquitous and extremely successful. I think this applies to some of your complaints about terminals as well. Yes escape sequences are ugly, but it means I can just emit the appropriate bytes from any program written in any language rather than figuring out what library I need to import to generate a correctly formatted structured message, and operating on the byte stream level lets it transparently work across remote connections. I'm all for experimenting with new approaches, but we shouldn't lose sight of the existing benefits.

mandibles 2y ago

While we're at it, can we get rid of staggered keyboards? We don't need to accommodate mechanical linkages from the bottom rows any longer, yet here we are. As other commenters have pointed out, once conventions and standards have been adopted, there is almost no way of dislodging them. It's a coordination problem. New standards and approaches usually need to be at least a 10x improvement over the status quo in order to be adopted organically. The same story applies to all areas of human endeavor.

9dev 2y ago
Im not so sure. We have HTTP3 now, which is binary. We use different image formats than we used to, and switched from horses to cars, too. Why shouldn’t we be able to innovate in this space? Building new walls doesn’t automatically imply tearing old ones down.
- wang_li 2y ago
  > Building new walls doesn’t automatically imply tearing old ones down. But often in this space they seem to want to do that anyway. I can only imagine that they are attempting to force people to adopt their pet project. There's literally no reason a pair of sequences can't be specified that allows clients to query support for advanced terminal mode and get a response. After the client and the terminal have agreed on advanced mode, switch to a byte stream/command blocks/whatever which allow rich text, graphics, sound, access to UI devices, etc. Whan you're done you've recreated X11, but they can do whatever they like I guess. There's no need to fuck up terminfo along the way though.

ykonstant 2y ago

Arcan is one such effort, but I am not sure what state the project is in.

bashinator 2y ago

In my opinion, the Lindy Effect[0] makes a lot of sense in scenarios like this. Personally, I love the fact that the slower evolution of command-line tools gives my personal skillset a longer shelf life. I can add additional capabilities without having to constantly re-learn how to do established work. [0] https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect

PurpleRamen 2y ago

> But I wish there was an effort of building a new, modern, textual interface to computers with modern assumptions and integration bindings. Would it be different from a web-browser? Isn't the webstack already the modern textual interface everyone is using? I mean that's also the direction they all are walking to, with adding images to terminals, having more complex layout with TUIs. I think I remember some TUI-toolkit which even used a limited CSS for describing their interface. And there are some terminals and alternatives which are build with NodeJS and webstack IIRC. So would it make more sense to find some proper standards for webstack-based cli-interfaces?

9dev 2y ago
> Isn't the webstack already the modern textual interface everyone is using? I would argue that the web stack is really more of a virtual machine, or OS-agnostic application runtime, but it is not a textual interface per se (albeit it certainly can be used that way). On the other hand, I'm looking for solid primitives to make applications talk to each other, but with structured data instead of plain text open to liberal interpretation; for terminals that don't emulate a teletype device, but make use of modern operating systems. Think of what we had before systemd—the wild west of shell scripts, layers upon layers of arcane compatibility hacks—and what we have now—a standardised, documented, structured, system management interface that works the same way everywhere (please don't lets discuss systemd here, it's just an analogy). So rather than trying to paint NodeJS-lipstick on the TTY-pig, I'd like to see a new kind of terminal protocol that solves the UX issues of old.
- PurpleRamen 2y ago
  > I'm looking for solid primitives to make applications talk to each other, but with structured data instead of plain text open to liberal interpretation JSON exists. YAML exists. XML exists. The lack of proper exchange-formats is not a problem. The lack of tooling is the problem. > Think of what we had before systemd—the wild west of shell scripts Liberty. And this gives you an answer why terminals, shells and cli in general remain this way. People have the liberty to do what they need, and they have the liberty to go as simple or complex as they want. And this works very well. Don't forget that not all output is structured. So unless you have someone creating a whole new set of tools and environment which can compete with the established solutions, and beat them on ALL aspects, and is still compatible...until then people will not support it. I mean, there are more than enough alternatives who are barely popular for one reason or another. Speaks for itself. > I'd like to see a new kind of terminal protocol that solves the UX issues of old. Which are the issues? Is there some solid documentation on them?

revscat 2y ago

> There is more to shells and text interfaces than working within constraints set 50 years ago. Of course. With some minor changes, you could make the same argument many, many technologies we use every day, from IPv4 to SQL to C. Then there is the old saw -- likely apocryphal -- about how railroads are the width they are because they evolved from standards around Roman roads. Even if it is a fairy tale, the moral of that story strikes true: existing tools are built on top of old ones, because it was better to have a standard then even if we may know better now.

9dev 2y ago
IPv4 is a great example, because the transition to IPv6, albeit slow, is happening. And that is an all-renewed protocol with a lot of previously impossible, awesome features. There is a way to do this right.
- NackerHughes 2y ago
  It’s also exponentially more complicated, has addresses that are a mile long and impossible to memorise, and has enabled such marvels as a toaster that outright refuses to make you breakfast unless it’s connected to the internet with an active subscription and all the telemetry that comes with it. Truly a great example of a way to do things right.

deleted 2y ago

[deleted]

theamk 2y ago

Is there? Lets put a few reasonable requirements down: - Self-sufficient commands that you can store in history, put on wiki page, put inside a script file, Slack to your friends, store in configuration, etc... - Variety of execution methods: local computer, remote via ssh, jupyter-like notebook, remote via something else (like AWS SSM), CI runner, ssh which launches SSM session which connects over serial port, cron-like periodic schedulers, starting commands in your Go program etc... Every method should be supported automatically with no effort from developer. - Output could be interactive (possibly with some reprocessing like tmux/screen does) or stored (like CI/cron execution). It is possible to parse output to get relevant details. Even if you start from scratch, what can you design to fit this pattern? You'll get something very close to existing state - applications that take command lines, character-based input/output streams with some sort of formatting sequences. Sure, if I could design from scratch I'd standardize on _one_ TERM, make escape sequences easier to parse (longer and common start/end chars), fix extended keys/numpad mess, redesign the CLI defaults of the few tools, create common command-line completion interfaces... but the overall idea will be the same. (And if you don't care about the three requirements above, then go with HTML or native UI! There are tons of them and they are well supported. But I don't see the point of retrofitting HTML-like functionality to exiting terminals)

9dev 2y ago
There definitely are more options than applications reading and writing character streams, you’re just not even considering them because you’re too entrenched in the environment you’re familiar with. Take Powershell for example; the syntax may be horrible, but the way it passes structured data is truly different and way ahead of classic UNIX shells. The design space is huge; just dismissing any possible improvements before even sitting down and thinking properly is frankly not a good strategy.
- theamk 2y ago
  If the design space is so huge, how about giving some examples, instead of insulting people who disagree with you? Surely you'll be able to do so, while satisfying the requirements I listed? Because Powershell doesn't satisfy them. You are not going to save Powershell object stream yo CI output or provisioner logs. You are not going to send objects over SSH, or over web console, or over BMC-emulated serial port. In all of those cases it's going to be good old stream of characters, with the occasional control sequence from more advanced programs. You can have whatever rich datatypes inside your application (powrshell isn't the first, I remember reading about LISP shells back in 2000's), but at some moment you have to talk with other systems, and that's when you will have to switch to character streams. (that said, the current escape sequences could use lots of improvement. That's not going to change fundamental concept though)

Ferret7446 2y ago

Chesterton's Fence is in full effect here. Quite a few people have tried to do exactly what you wish. They haven't really succeeded, obviously.