State of the Terminal

https://gpanders.com/blog/state-of-the-terminal/

by fanf2 • 2 years ago

104 157 2 years ago

nicce• 2 years ago

Just a shoutout how beautiful and powerful terminal editors can be if you invest some time to know the keybindings. There are some very powerful configurations and you don't need to invest that much time for configuration if you don't want to.

Currently, if you like visuals and want super fast experience, one easy (my favorite) setup is to install neovim, nvchad.com and (as extra neovide.dev)

eminence322• 2 years ago

A quick off-the-cuff remark based solely on the title: in 2024, I think the state of the terminal has never been better, in large part to Microsoft making a high quality terminal easily available to everyone on Windows [1]

As an application author, I love being able to assume that all major platforms have a good terminal and that my favorite terminal rendering libraries should Just Work on all of them

[1] https://github.com/microsoft/terminal

blueflow3• 2 years ago

I really dislike that they re-used the TERM value from xterm instead of getting their own merged into terminfo. And then not documenting which sequences are actually supported and which aren't.

ranger_danger3• 2 years ago

They have their own, and it's documented.

https://invisible-island.net/ncurses/terminfo.src.html#tic-m...

Surely you can imagine that it takes years or more to get people to update though, so switching to a new entry right away could make for a bad user experience.

tristan9572• 2 years ago

You would be surprised how much software is built exclusively for TERM=xterm or TERM=xterm-*.

hiccuphippo2• 2 years ago

Sounds like the user agent string in web browsers.

eej71• 2 years ago

I mainly use microsoft terminal now just beacuse it did a better job handling more of the font decorations (italic was one that I recall). My one gripe though is that it seems like microsoft terminal is still kind of slow at scrolling. If I accidentally grep for something that spews a lot to the screen, terminal is just plain hung up a bit. And for many of us - but not everyone? - control-space in emacs is just kind of broken. Long standing open issue for that one.

argulane• 2 years ago

Have you turned on the new render engine in the microsoft terminal settings? It is marked beta but should be much faster.

Longhanks2• 2 years ago

True, but no matter the terminal, you still have to deal with either cmd or PowerShell (and its horrendous startup time), "active code pages", and the fact that you cannot write UTF-8 to stdout without it getting messy - you need WriteConsoleW and/or SetConsoleOutputCP but that affects the whole environment, ... cli on Windows was and is painful.

pjmlp10• 2 years ago

PowerShell 7.4.2 starts in 1s for me.

zubairshaik• 2 years ago

You can run WSL or nushell on Windows Terminal

pjmlp10• 2 years ago

Yes, although thankfully on Windows we have a modern graphical terminal, with a scripting language that took plenty of learnings from non-UNIX CLIs into account.

hiccuphippo2• 2 years ago

Does this mean I can run the Build Your Own Text Editor[0] tutorial in Windows without WSL? I did it in Linux a few years ago, recently heard of Crossterm[1] and was thinking trying to remake it with that, but maybe it's not necessary?

[0] https://viewsourcecode.org/snaptoken/kilo/

[1] https://github.com/crossterm-rs/crossterm

eminence322• 2 years ago

Crossterm does indeed work well under Windows Terminal. I use it indirectly via the ratatui library[1]

[1] https://github.com/ratatui-org/ratatui

_lvbh• 2 years ago

Modifier keys like Ctrl and Alt complicate this situation.

This is such an understatement. Alacritty required you to manually bind keys to control characters in the config and finding the control characters escape sequences were such a nightmare I gave up and switched to foot

jprete• 2 years ago

The wonkiness of modifier keys is a constant barrier whenever I try to do anything to make a terminal environment more ergonomic. In the end I always go back to 100% IDEs and GUI document editors.

mixmastamyk6• 2 years ago

Looks like VTE finally fixed their bug regarding Ctrl+arrows etc. I have few issues now.

mg• 2 years ago

The terminal is such a wonderful environment. It makes many tasks joyful.

I think it stems from its simplicity and logic.

You have a simple grid of characters. You type the name of a program, hit enter, and the computer executes it. The output of the program is written below your prompt. Below the output, you can execute the next program. You can chain output and input of programs, allowing all kinds of data flows. The programs can also take over the whole grid and thereby allow all kinds of interfaces.

I can't think of a way to describe a window manager or a browser in similar, simple terms, which would explain the basis of all the usefulness they bring.

unshavedyak2• 2 years ago

Agreed. My only real problem is that font size and "UI" size (gutters/etc) being tied feels like an accessibility tax. Aside from that, they're wonderful.

I wonder if we could eventually make a "new term" which shares the same foundation, but atop a rich rendered experience. A GUI written with simple primitives (that could also probably be rendered as TUI, frankly), but with slightly more slick (and expensive lol) rendering.

I know, i know - blasphemy, i'm sorry. But despite my love for the Term (i've been in it for ~15 years now) i long for _slightly improved_ graphics.

mbrumlow• 2 years ago

It’s called emacs.

skulk• 2 years ago

Emacs seems to fit what you're describing pretty closely. It can render as a GUI and TUI even though the GUI can display things the TUI can't (like fonts/images)

necrotic_comp• 2 years ago

Agreed with the siblings, you're describing emacs! :)

inguz• 2 years ago

Retro-plug: here's a Teletype ASR33 simulator with sound https://www.youtube.com/watch?v=jd5oomwEBb0

ilaksh• 2 years ago

It would be nice if more terminals other than xterm would support Tektronix vector graphics.

https://github.com/bennetyee/TekGraphics

Here's an emulator for those specific real terminals: https://github.com/rricharz/Tek4010

kergonath• 2 years ago

I don’t really want vector graphics, but more support for sixels would be massively helpful.

lambdaba• 2 years ago

Are there any efforts to radically reimagine the entire "terminal" concept? Seems very limiting to advance further in the 21st century with those same 70's technical assumptions.

[edit] I was thinking more in terms of being unconstrained by low-res displays, inability to display anything other than text, etc.

ranger_danger3• 2 years ago

What do you suggest?

geor9e• 2 years ago

Different person here, but I wish there was a terminal where mouse clicks moved the text cursor (without holding any hotkey), mouse drags selected text and typing replaced the selected text, ctrl-A selected the entire current command (all the text after $ ), holding left/right arrow went WAY faster…

Basically, if you know how to competently edit an email, you shouldn't struggle in frustration at editing a big terminal command. I believe that some day there will be a terminal app you can sit a kid down in front of, and they're be able to fix a typo without any frustration or special knowledge. That day hasn't yet come.

I get the historical traditions for why terminal is the way it is, and I get why people who already know the secrets don't care to change it, but IMO it's time to move on.

bongobingo1• 2 years ago

Maybe some kind of subscription service?

dartos10• 2 years ago

What assumptions specifically?

Terminals, at the protocol level, assume nothing. It’s just streams of bytes which are processed then rendered.

The protocol makes no technical assumptions, which is why it has both lived so long and is such a mess

Bjartr5• 2 years ago

One assumption is that it's one stream of bytes (Okay, two if you count stderr) and so control and metadata has to be interleaved with content to be displayed

red_admiral• 2 years ago

There have been many unsuccessful such efforts. I'm only half joking if I say "the web" has been the most successful one to date. Or maybe "the browser window" is more precise, here.

The terminal is an odd, but historically understandable, mix of an API and a user interface, with the added UNIX flavor of "if everything communicates through text streams, then everything can talk to everything else" - which includes both humans and other programs. The clean way to go these days is of course to separate the two out (though on the terminal, arguably a REST endpoint is a also kind of user interface).

Powershell is a candidate for the "terminal reimagined" award in the sense that you're passing around structured objects rather than text streams internally, and so avoiding a lot of escaping/injection badness, even though the UI is a terminal window (but with a lot more autocomplete etc. features). (Personally, I hate its syntax, but that's a matter of style.)

The moment you want to go down the "UI reimagined" route while keeping as much cross-platform compatibility as possible, you end up with HTML/CSS and the layer of your choice on top of JS.

mixmastamyk6• 2 years ago

A few have kicked the tires but the fact you’d have to “boil the oceans” and rewrite every program and script in existence makes it a huge amount of work.

You’d most likely have to maintain backwards compatibility also, so you’d just create N+1 complexity, rather than simplifying things.

MisterTea• 2 years ago

Plan 9 dropped the concept and went graphics first using a 2D engine called devdraw which you load assets into and issue draw commands. Text is a first class primitive so drawing text is pretty simple. It has a shell but it lacks cursor control so stdout/stderr is written to the window's /dev/text - think of a window as a dumb textbox. If you need vt100 emulation you run the command in vt(1) which is a graphics program which emulates a tty terminal. When you run a graphical program from the shell it opens in the same window as it should because the window is more like a canvas. The window manager Rio(1) just multiplexes the /dev/draw device so you can run any graphical program from the initial graphical terminal - a window manager not needed. You can also run rio in rio as much as you want - its devdraw all the way down. If you really wanted to preserve a TUI program you could run in vt(1) or I think there is a curses library that does draw stuff on the back end skipping the vt emulation.

In this day and age I see no reason to perpetuate the tty terminal outside of Unix as it's an obsolete concept.

theamk4• 2 years ago

that sounds like a replacement for X11/Wayland, not for the terminal.

and this of course sounds fine and nice, until you need to interop with other machines / OS-es - in which case you open vt and ssh to whatever location. Or you want your application to be callable by other machine (or via ssh or from script or cron...) - in which case you eschew all the draw commands and do good old print. And now we are back to where Unix is.

albertzeyer2• 2 years ago

There have been many. But none of them really successful, in the sense that they were more proof-of-concept, never fully feature-complete, or just not adopted by the community.

See the list here: https://github.com/hoeck/schirm

I think the most popular was TermKit (https://github.com/unconed/TermKit, https://news.ycombinator.com/item?id=30517205).

Maybe the most successful such attempts is DomTerm (https://domterm.org).

pjmlp10• 2 years ago

Yes, back at ETHZ, Xerox, TI, Genera,....

The terminal is a full graphics REPL, working in tandem with the mouse, and the languages have full access across the whole OS stack.

Even if its syntax is not loved by everyone, Powershell is the closest we have to it.

bitcompost• 2 years ago

You might be interested in Arcan desktop engine ( https://arcan-fe.com ), which has a tui api for clients. It has been used to build an interesting experimental shell: https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lash...

joouha5• 2 years ago

This is a nice summary.

It would be good if there was more emphasis on graceful degradation in TUI libraries, such as falling back to ASCII art when terminal graphics are not supported.

Some new TUI libraries, such as vaxis, are designed specifically to avoid using terminfo at all and exclusively use queries to determine feature capabilities.

I take this approach in euporie [1], having encountered the same issues with using terminfo as discussed. However, there were a few terminal features which I could not find a way to query - iTerm2 graphics support, for example.

[1] https://github.com/joouha/euporie

joouha5• 2 years ago

Do any terminals support overprinting? This could radically change what is possible in TUIs

yjftsjthsd-h8• 2 years ago

I don't know about overprinting per se, but you can already use whatever foreground+background colors you want; how much benefit would overprinting be?

joouha5• 2 years ago

This would allow more complex shapes to be drawn by combining multiple glyphs, which would be useful for complex TUI applications (there are only a limited number of box-drawing characters available) Also, this could allow drawing more than two colours per terminal cell.

9dev14• 2 years 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• 2 years ago

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

hnlmorg7• 2 years 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.

pjmlp10• 2 years ago

Only in regards to UNIX CLI tools, computing history is full of other kinds of command line interfaces.

bmitc2• 2 years 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.

dooglius• 2 years 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.

dartos10• 2 years 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.

9dev14• 2 years 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.

Borg34• 2 years 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• 2 years 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.

bmitc2• 2 years 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.

9dev14• 2 years ago

First, dont like it? Dont use it. No need to cry over it.

I have to use it. That's the point. The CLI is an important and great piece of technology; I just don't love the way things are, and would prefer to see them improved instead.

Second, dont like it? Write something better, do show case and maybe people like it and start using it.

This is not how stuff like that works. Terminal interfaces are an ecosystem; there are a lot of different projects attempting new approaches, but there's no shared sense of the existing problems—as proved by your comment. I've written my original comment to make more people aware of those issues, increasing awareness.

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, it's everywhere so I can run stuff on platforms that problem existed before you were even born.

I didn't argue for that; in fact, I didn't even argue for removing the existing legacy stuff. Maybe try reading the original comment again? Just because we have a working solution doesn't mean we should stop innovating. There are tons of UX improvements possible beyond rendering emojis, such as proper inter-process message passing via standardised interfaces- just imagine piping from `ls` to any other process, and have that process know that it just got a list of file references, instead of a bunch of characters (Powershell does something similar). Let terminals offer completions like IDEs do. Let them render proper progress bars, without abusing braille characters. There's so many things people do just because they did them like this since forever, they stop questioning if there isn't a better way.

fipar• 2 years 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.

mynameisvlad• 2 years ago

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.

There’s “let them figure it out” and there’s “this is unnecessarily complicated because of archaic legacy compatibility”. It should not take multiple parameters to untar+gzip a file.

There is absolutely no reason why, if you provide tar a single .tar or .tar.gz with no other parameters, it doesn’t just say “ok this is a tar/gzip file and you probably want to extract it”.

yjftsjthsd-h8• 2 years ago

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

At least with GNU tar (and I think Darwin and some others), compression doesn't matter any more; `tar -xf foo.tar` correctly autodetects the compression and extracts even when foo.tar is gzipped.

9dev14• 2 years ago

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.

Well; as I said, I'm absolutely not arguing for somehow removing that feature—having the existing terminals continue working is definitely unavoidable, for the reasons you stated. However, that shouldn't mean there's zero movement in the space. We have several coexisting approaches to everything from operating systems to processors to web browsers; keeping legacy software functional shouldn't be an argument to hinder innovation in the entire space.

All the tooling that deals with json, yaml, etc is still parsing strings, and I prefer that to a binary format in most cases

There is a subtle difference here: A tool reading JSON from standard input and parsing that is just parsing strings, too, yes. However, what about a platform that passed messages from one tool to another on some kind of channel designated for passing JSON messages, exclusively? I don't think we should just have a --json parameter for GNU utils, but really a formalised way for unrelated applications to exchange data, without each of them having to fend off parsing errors. And reality right now is even worse, with every one of those utils having their own, bespoke output format.

Re: ANSI escaping: This ties into the same point. Applications should have more to their disposal than just reading and writing strings. If there were a way to attach metadata to input and output, we could pass on stuff like what should be coloured how, without requiring escape code parsing downstream. I'm inclined to agree with you on all of this being intensive effort-wise, but that hasn't deterred us in other cases either.

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.

I can see where you're coming from, but that's just gate keeping. The terminal is great interface, but does it really have to as undiscoverable? IDEs offer so much introspection into source code-- why can't we even have that for the terminal (except shell-specific completion hacks, which are just a poor approximation of what we should have). I'm not saying we should dumb it down to enable any fool to extract that archive, but UX-wise, it could be a lot easier to learn how something works. And yes, tar was a bad example. How about, say `ip`? Been using it for years, and still cannot remember how to do basic stuff with it without looking it up.

Workaccount23• 2 years 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• 2 years 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.

yjftsjthsd-h8• 2 years 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?

pjmlp10• 2 years 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.

orangecat2• 2 years 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...

9dev14• 2 years ago

Could you share what you mean by that? I suppose it was sarcasm, but I didn’t get the point.

mandibles• 2 years 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.

9dev14• 2 years 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.

ykonstant• 2 years ago

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

bashinator• 2 years 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

PurpleRamen2• 2 years 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?

9dev14• 2 years 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.

revscat2• 2 years 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.

9dev14• 2 years 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.

theamk4• 2 years 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)

9dev14• 2 years 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.

Ferret7446• 2 years 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.

deafpolygon• 2 years ago

That's why I appreciate MS's efforts to improve PowerShell and Terminal.

albertzeyer2• 2 years ago

I really would like to have:

* text folding (https://gitlab.freedesktop.org/terminal-wg/specifications/-/..., https://stackoverflow.com/questions/52812618/ansi-escape-seq...)

* graphics (https://gitlab.freedesktop.org/terminal-wg/specifications/-/...)

I wonder a bit why all those next-gen (often HTML-based) terminal attempts have not been successful (e.g. TermKit: https://news.ycombinator.com/item?id=30517205). Probably because SSH/Mosh/Tmux concepts are difficult to take over there, and those are somewhat crucial. And text folding or graphics also would have issues w.r.t. those (see also the linked discussions).

DomTerm (https://domterm.org) supports both those features, but it does not work with Mosh+Tmux, which is my main use case.

alain94040• 2 years ago

Accept a subset of html as a tool output? So if a CLI tool wants to output a list just do:

  printf(“<li>item 1”);

And legacy tools are obviously supported as raw text since their output doesn’t start with a magic html tag.

morning4coffe• 2 years ago

Exciting to see the state of the terminal evolving! While there's a lot of legacy to contend with, efforts like Microsoft's new terminal are definitely steps in the right direction. It's a fascinating area to watch, and I'm curious to see how tools like the alternative shell and terminal emulator mentioned will shape the future of text interfaces

thibran• 2 years ago

I love the abstract idea of the command-line, but not it's textual implementation. The best currently available old school shell is Nushell IMHO.

What I really want is a GUI that works like a command-line, but with rich media and mouse support. Instead of 100% key input I would sometimes like to click and add/remove/filter data.

The terminal is so useful, still it's strange we tolerate up to this day all it's shortcomings.

barfbagginus• 2 years ago

I have transitioned to a category theoretical terminal interface (CTTUI). At this terminal, whenever I have an idea and I want to see it in practice, instead I think about some nice happy functors dancing in some nice happy 2-category of functors and natural transformations. Sometimes I will draw a string diagram proof that looks like a bowl of spaghetti, which makes me hungry. Very soon the desire to use a computer passes. And that is how 50 years of awful terminal tech debt is universally avoided, just by tapping the power of categories!

bainganbharta• 2 years ago

As expected, a bunch autists arguing in here.

DaSHacka3• 2 years ago

Where have you seen arguing?

Unless moderators purged a bunch of comments, seems like people are just discussing the history of terminals and how they could be improved going forward.

waynesonfire• 2 years ago

I use dvorak keyboard layout and the "." is a prime real estate location on the keyboard. Unfortunately, ctrl+. does not work in emacs over terminal.

1vuio0pswjnm72• 2 years ago

"This has a multitude of problems, however. The terminfo database is part of the ncurses library, and different operating systems and distributions package different versions of ncurses. This was a problem for tmux users on macOS for many years because the version of ncurses packaged with macOS was so old that it did not even include the tmux-256color terminfo entry at all!"

I build static Linux userlands from scratch using only busybox/toybox and a statically-linked GCC.

When compiling programs, e.g., tmux, I have been using netbsd-curses instead of ncurses.

After I compile tmux statically, the terminfo entries needed by tmux, i.e., needed by the curses libraries compiled into it, are contained by default in the directory $HOME/.terminfo. If nothing is found there, tmux then checks /usr/share/terminfo (or whatever path was use when compiling, e.g., /usr/local/share/terminfo).

This directory can of course exist apart from a curses library installed in a directory. In the userlands I make, there is no curses library installed in a directory after I have finished compiling all the programs.

For example, I can make a tarball of the terminfo directory from any suitable up-to-date distribution and untar it on the target computer.

Or I can make a hashed database of only the entries I need.

For me, the terminfo database is not "part of the curses library"; curses libraries provide an example terminfo database and a utility to compile terminfo entries. If the entries were truly part of the library, then one might argue they would be compiled into programs along with the library when compiling statically.

I keep a personalised copy of a terminfo database, i.e., a tarball of a terminfo directory, separate and apart from a curses library.

To be used with whatever curses library I choose. Not to suggest there is a great variety of curses libraries to choose from.

1vuio0pswjnm72• 2 years ago

NetBSD curses actually does compile a few terminal descriptions into the library

https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/lib...

ansi

dumb

vt100

vt220

wsvt25

xterm

Unfortunately, netbsd-curses for Linux removed vt220 while almost tripling the size of the list

I prefer vt220 am not interested in 256 colors

https://raw.githubusercontent.com/sabotage-linux/netbsd-curs...

xterm

linux

xterm-256color

ansi

dumb

vt100

screen

screen-256color

tmux-256color

rxvt-unicode

rxvt-unicode-256color

st-256color

dvtm

dvtm-256color

fbpad-256

State of the Terminal

Related Stories