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

Building the Future of the Command Line

github.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: Building the Future of the Command Line

#21

Post by rektide »

Kukumber wrote: post #11

"your server needs a GPU and an i5 to use our shell, as it provides a graphical interface and some shader animation because that's what attract the money people, they want shiny stuff y'know" This trend of "new modern shells" that runs and start as slow as some javascript code (powershell) needs to stop People forgot what shells are for, and what scripting is for

Doesn't seem like a real problem. Why are we grumbling about this? No one is making rxvt less an option. Why the fear? Why the negativity?

Does start-up time matter? Who cares? (I have three terminals that have been open for almost a year.) Are we concerned about only first start, or primarily the faster second starts once all the dynamic libraries have loaded? Does anything actually require an i5? Whats wrong with requiring a GPU?

Doesnt it get tiring, being so grumbly about other people having fun & doing cool things? Do you really think we should do as you say & just freeze time, insist on doing nothing?

Re: Building the Future of the Command Line

#22

Post by 0x0203 »

an1sotropy wrote: post #18
scj wrote: post #4

Earlier quoted context omitted.

I've always wondered about expanding stdin, stdout, stderr. Say, stdjson that doesn't get visually displayed, but can be piped (and would only be generated if it is needed on the pipe stream). ls | cat With the direct ability to process in line: ls -a | json.files[0].last_modified I'd probably want multiple output formats (including s-expressions).

(fully daydreaming here) For C, would it be useful to have main() look like: int main(int argc, char *argv[], char *envp[], JSON *json) for some JSON data type that is part of C, kind of analogous to a FILE stream? I'm not sure how the the json info would get into that fourth argument (has to be independent of argv), but it would keep std{in,out,err} as is.

You would need to modify the execve system call (or equivalent non-Linux OS's) to take in the 4th json arg for the shell to pass when it exec's the new process. And then of course modify the OS kernel to parse/deal with it. But in reality, since you can't break the ABI like that for all existing software, it would end up being execve_2 or something and you'd have to both convince everyone else it's worth using, and deal with the inevitable incompatibilities when not everyone does. Not impossible perhaps, but certainly an uphill battle.

Re: Building the Future of the Command Line

#24

Post by ablob »

tambourine_man wrote: post #23

The future of the command line is something along the lines of what these guys are doing: https://www.textualize.io

Isn't this still confined to what a terminal gives you right now (as it is using current terminal specifications)? While certainly colorful and fancy, it doesn't really introduce new concepts, does it?

I mean, for starters:

   -> unix introduced text as a universal interface
   -> bash made reusing stuff a lot easier via file descriptors, etc. (think:  powershell allowed for object oriented scripting
   -> some older systems (name forgotten/unknown) even had interactivity in the cli: click on parts of command-output and stuff happens, even after other commands have been run already

Re: Building the Future of the Command Line

#25

Post by ablob »

abathur wrote: post #20
lgas wrote: post #16

Earlier quoted context omitted.

You might find http://docopt.org/ to be of interest. (It's available in many languages https://github.com/docopt ).

Parsers designed for implementing CLI programs are generally too opinionated to handle ~strange commands. (In my terms I'd say it's a prescriptive parser as opposed to something that attempts to be flexible enough to describe nearly all existing CLIs).

Wouldn't it be easier to have a convenient library/parser for almost all of the use cases instead of an immensely complex catch-all solution? Having custom logic when required should almost always be less complex when such a ~strange command is to be implemented.

Re: Building the Future of the Command Line

#26

Post by tambourine_man »

ablob wrote: post #24
tambourine_man wrote: post #23

The future of the command line is something along the lines of what these guys are doing: https://www.textualize.io

Isn't this still confined to what a terminal gives you right now (as it is using current terminal specifications)? While certainly colorful and fancy, it doesn't really introduce new concepts, does it? I mean, for starters: -> unix introduced text as a universal interface -> bash made reusing stuff a lot easier via file descriptors, etc. (think: powershell allowed for object oriented scripting -> some older systems (…

Sure, the terminal primitives are fixed unless we expand the standard.

But what they are doing is way beyond colorful only. It’s smooth scrolling of text boxes within text boxes. That alone is bonkers.

But they also have an easy API for smart/partial redrawing, sensible UI components, I mean, their progress bars are exquisite. It’s truly impressive.

Re: Building the Future of the Command Line

#27

Post by NotTheDr01ds »

scj wrote: post #4
an1sotropy wrote: post #3

One thing not discussed are the libraries used for command-line parsing (parsing argv), and how that might get complicated by shells trying to make the command-line into something effectively more than an array of strings. Having written a non-trivial command-line parser in C, and having used a bunch of them in other languages, it seems to me that this task would benefit from some more standardization and maturation.…

I've always wondered about expanding stdin, stdout, stderr. Say, stdjson that doesn't get visually displayed, but can be piped (and would only be generated if it is needed on the pipe stream). ls | cat With the direct ability to process in line: ls -a | json.files[0].last_modified I'd probably want multiple output formats (including s-expressions).

You seem to be pretty close to Nushell, which was mentioned in the article. The Nushell `ls` (and `ps`, etc.) builtins generate structured data that can be sorted, queried, reduced, and then transformed to many different types of structured data.

$ ls | get 0 | select modified | to json

{ "modified": "2022-08-16 16:38:28 -04:00" }

The internal data format looks pretty JSON-like, with the added ability to keep Nushell types intact.

While I'm not ready to replace Fish with Nushell, it's definitely taken the place of jq for me.

Re: Building the Future of the Command Line

#28

Post by e3bc54b2 »

How about Arcan? [0]

It seems very well reasoned, has stable API, excellent backwards compatibility and does not require GPU and i5 as this one might? Its author also has proven record and actual experience, which I'm not sure authors hpf TFA have, judging solely from their writing.

0: https://arcan-fe.com/

Re: Building the Future of the Command Line

#29

Post by abathur »

ablob wrote: post #25
abathur wrote: post #20

Earlier quoted context omitted.

Parsers designed for implementing CLI programs are generally too opinionated to handle ~strange commands. (In my terms I'd say it's a prescriptive parser as opposed to something that attempts to be flexible enough to describe nearly all existing CLIs).

Wouldn't it be easier to have a convenient library/parser for almost all of the use cases instead of an immensely complex catch-all solution? Having custom logic when required should almost always be less complex when such a ~strange command is to be implemented.

As I said, my usecase doesn't involve implementing the commands--it involves reliably identifying executables in the arguments to many different commands.

I can't go rewrite awk, find, and sed with an opinionated cli module. I have to deal with the current reality.

(you're roughly describing what I already do, and it scales poorly)

Re: Building the Future of the Command Line

#30

Post by frob »

I'm finding the text block with an overall left-to-right gradient surprisingly hard to read. Continuing from the end of one line to the beginning of the next takes more effort than it should. I'm guessing it's the abrupt change in color.

I've found the gradient text trend to be interesting for titles and single lines, but I don't think it works for multi-line text.

Post reply on HN