Live data from Hacker News

State of the Terminal

gpanders.com

61–70 of 159 posts

Re: State of the Terminal

#61

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://git…

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.

You can run WSL or nushell on Windows Terminal

Re: State of the Terminal

#62
post #21
post #17

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…

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 p…

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

Re: State of the Terminal

#63
post #17

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…

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.

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

Re: State of the Terminal

#64

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

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

  printf(“item 1”);
And legacy tools are obviously supported as raw text since their output doesn’t start with a magic html tag.

Re: State of the Terminal

#65
post #32
post #17

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…

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…

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

Re: State of the Terminal

#66
post #41
post #17

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…

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 rev…

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

Re: State of the Terminal

#67
post #41
post #17

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…

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 rev…

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

Re: State of the Terminal

#68
post #22

Earlier quoted context omitted.

What do you suggest?

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 termina…

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

In BASH, set $EDITOR to whatever you want - even a GUI editor - and then hit (by default) ctrl-x ctrl-e and it'll open the current line in your editor and when you save+close the editor the command will run.

https://unix.stackexchange.com/questions/85391/where-is-the-... seems like a decent discussion of the feature, and its footguns (it does execute whatever was in the buffer when you close the editor without confirmation), and even some talk of how to improve it a bit.

Re: State of the Terminal

#69
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

Re: State of the Terminal

#70
post #16

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

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?
Post reply on HN