Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of the Terminal

gpanders.com

Post reply on HN
Print view View original

121–130 of 159 posts

Re: State of the Terminal

#121

Post by 9dev »

yjftsjthsd-h wrote: post #102
9dev wrote: post #95

Earlier quoted context omitted.

> 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? Please don’t take it personally, but I find it a bit sad that your imagination ends here. These two questions depend entirely on the chosen implementation. If we’re talking about a new implementation, should we really…

> I find it a bit sad that your imagination ends here. This isn't the limit of what's possible, it's a lower bound of questions that you have to answer if you want to build a replacement. > These two questions depend entirely on the chosen implementation. Okay? Feel free to include multiple answers, but you need at least one. > If we’re talking about a new implementation, should we really start by accepting the limit…

Instead of a specific key combination that a) clashes with the way the vast majority of computer users enter text, b) is neither obvious nor easily discoverable, and c) not available or awkward to enter depending on the input device, we could also separate the monitoring of running processes from the command prompt and let the terminal application offer a control to cancel them, or match modern user expectations and do so using the Escape key. Or entirely different.

The point is that we don't use ^C because it's ergonomic or obvious, but because of conventions inherited from a time long gone. Keeping legacy software running does not imply imposing the same UX constraints on users.

Re: State of the Terminal

#122

Post by 9dev »

Borg3 wrote: post #107
9dev wrote: post #73

Earlier quoted context omitted.

> 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; t…

Well, innovating or start bloating? Usually I see things being overengineered because we MUST innovate. No innovation = going backward. Progress bar? what for? Is something like that not enough? Transmiting files: 3/20 (12%), 675kB/s Or sth like that. Far more informative that just progress bar. And can render anywhere, easly, over 9600bps too.

Sure, that is a progress bar. And it's something countless devs have wasted hundreds of man-years reimplementing over and over again, instead of delegating to the terminal application. Because we're stuck with handling transparent character sequences.

Re: State of the Terminal

#123

Post by dartos »

9dev wrote: post #100
dartos wrote: post #25

Earlier quoted context omitted.

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

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

I think it’s a fundamental design choice. It’s a double edged sword for sure, but it’s important.

It allows terminals to respond very quickly because they never need to wait for an entire data structure to download before displaying information.

It’s such a simple protocol that anyone can hack on it (which is a strength and weakness)

Asking to change that, in my mind, is like asking to change how packets move across a network. It’s all byte streams that get treated as structured data higher up on the abstraction layers.

TUI frameworks like the ones from charm.sh are built atop the base protocol and provide support for structured data much like how our network stack works. That way, as you were saying, application programmers don’t need to worry too much about the underlying “wire protocol”

The issue isn’t that terminals are stream-native or that they operate on byte codes instead of characters.

The problem is lack of standardization of said codes. Which leads to a mountain of edge cases in supporting every known terminal. That’s the cruft, not the minimal protocol

Re: State of the Terminal

#124

Post by dartos »

9dev wrote: post #119
camgunz wrote: post #110

Earlier quoted context omitted.

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.

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.

I don’t think it’s suboptimal at all. (How many bytes does it take to change the color of a single word in the terminal protocols vs the web for example)

It’s literally a wire protocol.

It’s minimal and designed to be easily abstracted away.

The suboptimal part is the lack of standardization.

Re: State of the Terminal

#125

Post by 9dev »

dartos wrote: post #124
9dev wrote: post #119

Earlier quoted context omitted.

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.

I don’t think it’s suboptimal at all. (How many bytes does it take to change the color of a single word in the terminal protocols vs the web for example) It’s literally a wire protocol. It’s minimal and designed to be easily abstracted away. The suboptimal part is the lack of standardization.

It may be a wire protocol, but it’s also the primary method of interaction with the computer for technical folk. Do we really have to constrain ourselves to a wire protocol here, or is there maybe room for something more user-friendly?

Re: State of the Terminal

#126

Post by hnlmorg »

pjmlp wrote: post #120
hnlmorg wrote: post #117

Earlier quoted context omitted.

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…

Amiga DOS !== UNIX CLI, and if you don't get why, well so be it, lets worship 1970's printer hardware instead.

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

Re: State of the Terminal

#127

Post by yjftsjthsd-h »

9dev wrote: post #121
yjftsjthsd-h wrote: post #102

Earlier quoted context omitted.

> I find it a bit sad that your imagination ends here. This isn't the limit of what's possible, it's a lower bound of questions that you have to answer if you want to build a replacement. > These two questions depend entirely on the chosen implementation. Okay? Feel free to include multiple answers, but you need at least one. > If we’re talking about a new implementation, should we really start by accepting the limit…

Instead of a specific key combination that a) clashes with the way the vast majority of computer users enter text, b) is neither obvious nor easily discoverable, and c) not available or awkward to enter depending on the input device, we could also separate the monitoring of running processes from the command prompt and let the terminal application offer a control to cancel them, or match modern user expectations and…

> Instead of a specific key combination that a) clashes with the way the vast majority of computer users enter text, b) is neither obvious nor easily discoverable, and c) not available or awkward to enter depending on the input device,

I grant that a) it's different from everything else, but b) CUA shortcuts aren't obvious or discoverable either, they're just more common, and c) I can't think of any device that has a terminal where ctrl isn't readily available. Nonetheless, I actually agree that if we could do it without breaking everything, moving everything to the same convention is compelling on its own. (Of course, I don't think we can do it without breaking everything, but that's life.)

> we could also separate the monitoring of running processes from the command prompt and let the terminal application offer a control to cancel them,

When I want a process dead, I want it dead now, not after I've found the mouse and hit a button. I also have concerns about how that button is going to actually work under the hood; the only options I can think of are that that sends a simulated ctrl-c, or the terminal emulator suddenly has to track child processes and decide what to kill (which strikes me as a bad idea).

> or match modern user expectations and do so using the Escape key.

And in so doing break anything that was using escape, like vi. Incidentally, the plan to intercept ctrl-c will break emacs, too. Which is why I strongly disagree with

> Keeping legacy software running does not imply imposing the same UX constraints on users.

because breaking legacy software is exactly the trade you're proposing.

Re: State of the Terminal

#128

Post by theamk »

9dev wrote: post #118
theamk wrote: post #112

Earlier quoted context omitted.

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

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…

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)

Re: State of the Terminal

#129

Post by dartos »

9dev wrote: post #125
dartos wrote: post #124

Earlier quoted context omitted.

I don’t think it’s suboptimal at all. (How many bytes does it take to change the color of a single word in the terminal protocols vs the web for example) It’s literally a wire protocol. It’s minimal and designed to be easily abstracted away. The suboptimal part is the lack of standardization.

It may be a wire protocol, but it’s also the primary method of interaction with the computer for technical folk. Do we really have to constrain ourselves to a wire protocol here, or is there maybe room for something more user-friendly?

We, as users, do not interact with the wire protocol. We type at generally very user friendly terminals, which abstract the wire protocol.

Even TUI devs don’t usually interact with the protocol directly, they use ncurses or something from charm.sh to abstract away the protocol.

Moreover, what “constraint” does using a wire protocol like this impose?

And how would one interact with any computer without a low level layer of byte-encoded information? (You can’t. It’s how computers work)

Re: State of the Terminal

#130

Post by ranger_danger »

yjftsjthsd-h wrote: post #68
geor9e wrote: post #22

Earlier quoted context omitted.

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

> without holding any hotkey
Post reply on HN