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

The terminal of the future

jyn.dev

Post reply on HN
Print view View original

161–170 of 174 posts

Re: The terminal of the future

#161

Post by forgotpwd16 »

naikrovek wrote: post #141

Make the terminal very simple and easy to understand. Rid us of the text-only terminal baggage that we deal with today. Even graphics are encoded as text, sent to the terminal, then decoded and dealt with. Plan9 had the terminal right. It wasn't really a terminal, it was just a window which had a text prompt by default. It could run (and display!) graphical applications just as easily as textual applications. If you…

The discussion is about the terminal as an interface rather the emulator/renderer specifically, or in this case the windowing system. So in Plan 9 you could've a GUI app overtake the root window but could you have graphics intertwined with text when working at the shell?

Re: The terminal of the future

#162

Post by forgotpwd16 »

fainpul wrote: post #158
rbanffy wrote: post #126

Earlier quoted context omitted.

I have a distaste for the verboseness of PowerShell, but I also have concerns with the attempt to bake in complex objects into the pipeline. When you do that, programs up and down the stream need to be aware of that - and that makes it brittle. One key aspect of the Unix way is that the stream is of bytes (often interpreted as characters) with little to no hint as to what's inside it. This way, tools like `grep` and…

> When you do that, programs up and down the stream need to be aware of that - and that makes it brittle. You can go from object- to good old text processing with *nix tools no problem. Instead of using 100% PowerShell to count all lines in the text files: gc *.txt | measure | select -ExpandProperty count you can switch to `wc` if you like: gc *.txt | wc -l `gc` is Get-Content – basically cat. You can also use awk, s…

What GP talks about is illustrated with the following modification of your example:

  PS /home/user> gc *.txt | measure | cat | select -ExpandProperty Count
  Select-Object: Property "Count" cannot be found.
  Select-Object: Property "Count" cannot be found.
  Select-Object: Property "Count" cannot be found.
  Select-Object: Property "Count" cannot be found.
  Select-Object: Property "Count" cannot be found.
  Select-Object: Property "Count" cannot be found.
  Select-Object: Property "Count" cannot be found.
  Select-Object: Property "Count" cannot be found.
  Select-Object: Property "Count" cannot be found.
Essentially at every step you need to consider whether the preceding command outputs objects or not. This isn't the case with the Unix way. The pipeline always carries a stream of bytes. You only have to consider how to interpret that stream.

Re: The terminal of the future

#163

Post by forgotpwd16 »

robot-wrangler wrote: post #50
skydhash wrote: post #13

I read the whole thing and at first glance, it seems like a whole NIH list of wishes. We already have alternatives to the terminal, but the article have no mentions of them: - Emacs (inherited from lisp machines?). A VM which is powered by lisp. The latter make it easy to redefine function, and commands are just annotated functions. As for output, we have the buffer, which can be displayed in windows, which are arran…

> Acme: Got a link to what you meant? This is pretty hard to search for. > - Emacs One thing in common with emacs, jupyter, vscode.. these are all capable platforms but not solutions, and if you want to replace your terminal emulator by building on top of them it's doable but doesn't feel very portable. I'd challenge people that are making cool stuff to show it, and then ship it. Not a pile of config + a constellatio…

A solution build upon Emacs is trivially portable by utilizing a custom init.el, setting the user-emacs-directory variable, and a script/desktop entry running Emacs with it. A solution build upon anything is, in theory, portable utilizing Nix/Guix.

Re: The terminal of the future

#164

Post by jcgl »

mongol wrote: post #135
jcgl wrote: post #108

Earlier quoted context omitted.

> Heresy warning. Maybe the inputs and outputs don’t look anything like CLI or stdio text. Maybe we move on from 1000-different DSLs (each CLI’s unique input parameters and output formats) and make inputs and outputs object shaped. Maybe we make the available set of objects, methods and schemas discoverable in the terminal API. Entirely agree. Stdio text (which is really just stdio bytes) deeply limits how composable…

Another question is if such pipelines should act on objects, or more structured text streams. Many programs can output json, is this a pragmatic way forward to extend and improve further?

Replying out-of-order to your points.

> Many programs can output json, is this a pragmatic way forward to extend and improve further?

Yes, json is a pragmatic way to put a band-aid on this issue. It really is Good Enough™ for many things, and shell tools that optionally emit json are strictly an improvement, imo.

> Another question is if such pipelines should act on objects, or more structured text streams.

"Structured text" is inherently brittle, compared to a self-describing message format. For one, even when you structure your text, you will always end up dealing with escaping problems.

Even worse, imo, is that backwards compatibility becomes a terrible challenge. Let me illustrate with a best-case scenario for structured text: ASCII-only tabular data (nested, binary, unicode data is left as an exercise to the reader, in true unix fashion). The most natural thing to do in unix is to select the relevant fields with awk. More specifically, you select fields by their number. Well, now your pipeline is tightly coupled to column ordering.

In principle you could use awk to select based on field names, those field names are just text and so it becomes incumbent on you, the pipeline author, to make sure they don't get lost in transit. No easy tail or grep for you!

All of this becomes avoidable when you deal with self-describing messages instead of raw bytes.

Re: The terminal of the future

#165

Post by jcgl »

forgotpwd16 wrote: post #162
fainpul wrote: post #158

Earlier quoted context omitted.

> When you do that, programs up and down the stream need to be aware of that - and that makes it brittle. You can go from object- to good old text processing with *nix tools no problem. Instead of using 100% PowerShell to count all lines in the text files: gc *.txt | measure | select -ExpandProperty count you can switch to `wc` if you like: gc *.txt | wc -l `gc` is Get-Content – basically cat. You can also use awk, s…

What GP talks about is illustrated with the following modification of your example: PS /home/user> gc *.txt | measure | cat | select -ExpandProperty Count Select-Object: Property "Count" cannot be found. Select-Object: Property "Count" cannot be found. Select-Object: Property "Count" cannot be found. Select-Object: Property "Count" cannot be found. Select-Object: Property "Count" cannot be found. Select-Object: Prope…

> Essentially at every step you need to consider whether the preceding command outputs objects or not.

This is true, no matter what language, paradigm, or even universe you're in; data that gets passed into a pipeline needs to have the abstract shape that the pipeline expects. This is always true, and it's every bit as true of unix byte streams.

You can of course have pipelines that try to coerce data or assert its structure. The PowerShell example you showed does the latter, and raises an error message that the assertion failed.

Unix byte streams do neither. There's no coercion, no assertion. Just blind trust. When you have IFS set incorrectly, you simply get a wrong answer. When you grab the wrong field number with cut or awk, you get a wrong (or empty) answer. The input data matters every bit as much with unix as it does with every other system of computation. What changes are characteristics like brittleness and enforceability of invariants.

Re: The terminal of the future

#166

Post by jcgl »

rbanffy wrote: post #126
jcgl wrote: post #108

Earlier quoted context omitted.

> Heresy warning. Maybe the inputs and outputs don’t look anything like CLI or stdio text. Maybe we move on from 1000-different DSLs (each CLI’s unique input parameters and output formats) and make inputs and outputs object shaped. Maybe we make the available set of objects, methods and schemas discoverable in the terminal API. Entirely agree. Stdio text (which is really just stdio bytes) deeply limits how composable…

I have a distaste for the verboseness of PowerShell, but I also have concerns with the attempt to bake in complex objects into the pipeline. When you do that, programs up and down the stream need to be aware of that - and that makes it brittle. One key aspect of the Unix way is that the stream is of bytes (often interpreted as characters) with little to no hint as to what's inside it. This way, tools like `grep` and…

> I have a distaste for the verboseness of PowerShell, but I also have concerns with the attempt to bake in complex objects into the pipeline. When you do that, programs up and down the stream need to be aware of that - and that makes it brittle.

Yeah, you definitely can't write tools for the unix shell that assume some kind of self-describing message encoding. I mean, you could, but you'd have to do a lot of work to wrap it so that it can work with unix byte streams at the edges. I believe oil shell and nushell have prior art on this. To your point, it should be telling that those are shells of their own, rather than tools for existing unix shells.

> One key aspect of the Unix way is that the stream is of bytes (often interpreted as characters) with little to no hint as to what's inside it. This way, tools like `grep` and `awk` can be generic and work on anything while others such as `jq` can specialize and work only on a specific data format, and can do more sophisticated manipulation because of that.

This seems backwards to me. grep and awk are extremely fragile because they have to look at what's inside. They have to read every byte, and the user of grep and awk must understand entirely what the incoming data will be.

Whereas with PowerShell or any other system with self-describing messages, the user makes some lightweight assertions about the abstract shape of the data--not the concrete shape of that data's representation.

Re: The terminal of the future

#167

Post by kevinrineer »

jkl5xx wrote: post #146
efitz wrote: post #74

Why does the successor to the terminal need to be text oriented at all? Maybe it is an API. Maybe the kernel implements this API and it can be called locally or remotely. Maybe someone invents an OAuth translation layer to UIDs. The API allows syscalls or process invocation. Output is returned in response payload (ofc we have a stream shape too). Maybe in the future your “terminal” is an app that wraps this API, auth…

Totally agree with all of your comment. To solve for structured data instead of everyone writing parsers, I’ve enjoyed using nushell (not affiliated, just love the idea). https://www.nushell.sh/ It’s like powershell but not ugly and not Microsoft.

I love the idea of nushell. Do you have any worry about the lack of portability of having and becoming so familiar with such a tool that you become reliant on it?

I have this feeling with most things that are not the "default", especially when I think of getting new tools adopted into a conservative workplace.

Re: The terminal of the future

#169

Post by fainpul »

forgotpwd16 wrote: post #162
fainpul wrote: post #158

Earlier quoted context omitted.

> When you do that, programs up and down the stream need to be aware of that - and that makes it brittle. You can go from object- to good old text processing with *nix tools no problem. Instead of using 100% PowerShell to count all lines in the text files: gc *.txt | measure | select -ExpandProperty count you can switch to `wc` if you like: gc *.txt | wc -l `gc` is Get-Content – basically cat. You can also use awk, s…

What GP talks about is illustrated with the following modification of your example: PS /home/user> gc *.txt | measure | cat | select -ExpandProperty Count Select-Object: Property "Count" cannot be found. Select-Object: Property "Count" cannot be found. Select-Object: Property "Count" cannot be found. Select-Object: Property "Count" cannot be found. Select-Object: Property "Count" cannot be found. Select-Object: Prope…

jcgl already answered this well. My example was merely to show that you can go from PS objects to old fashioned text processing without issues. Any non-PS tool will just receive the text representation of the objects – exactly as you see them in the terminal. I wasn't trying to imply you can go back and forth between them like magic (which should be obvious).

Once you have lost the objects and work with simple text, you have to use the text processing tools of PS, if that's what you want to do. To continue your example:

  gc *.txt | measure | cat | sls count
sls (Select-String) is like grep.

(Note: this example is nonsense, just to show that it works)

Re: The terminal of the future

#170

Post by fainpul »

kevinrineer wrote: post #167
jkl5xx wrote: post #146

Earlier quoted context omitted.

Totally agree with all of your comment. To solve for structured data instead of everyone writing parsers, I’ve enjoyed using nushell (not affiliated, just love the idea). https://www.nushell.sh/ It’s like powershell but not ugly and not Microsoft.

I love the idea of nushell. Do you have any worry about the lack of portability of having and becoming so familiar with such a tool that you become reliant on it? I have this feeling with most things that are not the "default", especially when I think of getting new tools adopted into a conservative workplace.

If you want to adopt it in your workplace, I would not recommend nushell. They have severe, long standing bugs which don't get fixed. The most annoying to me is output formatting:

https://github.com/nushell/nushell/issues/13601

https://github.com/nushell/nushell/issues/16379

Post reply on HN