Live data from Hacker News

Building the Future of the Command Line

github.com

31–40 of 75 posts

Re: Building the Future of the Command Line

#31

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/

Um, how do you use it? I've tried like five times and I keep bouncing off the project.

Re: Building the Future of the Command Line

#32

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/

Um, how do you use it? I've tried like five times and I keep bouncing off the project.

NixOS has a nice module that can be easily enabled. After that default DE durden can be invoked with single command and can be interacted with as a normal VM/Window alongside your existing DE.

Admittedly I haven't tries making it my default yet, but seemed fairly well adaptable for tiling WM/Openbox needs.

Re: Building the Future of the Command Line

#33
post #21

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

I care. I care about start up time. I care because I just had a black out, and that requires booting, I care because I mess with my system and I have to reboot sometimes. I care because I expect software to improve, not get worse. I care about engineering because bad engineering ultimately wastes my time and everyone elses. Everyone can have fun and nobody should prohibit others from doing so. but valid criticism is valid criticism, even though I hate it.

With that said, the counter argument should've been that although powershell does start up slow, (and many other things) it is better than bash in many cases and more performant.

Re: Building the Future of the Command Line

#34
post #10

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 have a hard time imagining how we get out of the gravity well of CLI programs handling their own parsing. A tool I write has a use-case for understanding the syntax of at least ~common CLI tools well enough to pick out args that will be other executables (sudo cat, find blah -exec...), so I have been idly pondering whether there's a humane, declarative, descriptive grammar that can express nearly all CLI interfaces…

You might find Fig completion specs useful for this: https://github.com/withfig/autocomplete

Re: Building the Future of the Command Line

#35
post #24

Earlier quoted context omitted.

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.

[deleted]

Re: Building the Future of the Command Line

#36
post #21

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

> Does start-up time matter? Who cares?

Yes, me

> being so grumbly about other people having fun & doing cool things

The downstream effect of people "doing cool things" (making insanely bloated crap) is that we often have to use it.

I don't understand this attitude that every claim and endeavor is immune from criticism as long as you can frame it as someone "having fun" (I'm sure these corporate software projects are super duper fun) or being experimental.

Re: Building the Future of the Command Line

#37
post #4

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

What about an ioctl that lets you query what formats are accepted by the file descriptor? We already sort of have a precedent for it with giving different output based on isatty().

Re: Building the Future of the Command Line

#38
> One of its modules attempts to translate natural language requests into the correct shell commands and syntax. For example, if you typed “compress Documents folder,” CLAI will recommend the corresponding Tar command.

This is such a bad idea I don’t know where to start. Shell commands are a dangerous, but precise tool, somewhat like using a scalpel or a surgical tool. Dumbing it down so it can “guess what you want it to do” is going to result in more people (Specifically people who don’t bother to read the docs) breaking things.

Re: Building the Future of the Command Line

#39
post #21

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

> Whats wrong with requiring a GPU?

I'm glad that you never encountered this before and I sincerely wish you never will: getting on call 3am in the morning due to server outage and you couldn't diagnose remotely. You rushed to the server room, which was only 50F btw, connected to the machine and brought up a rescue shell. Oh, did I tell you that none of them has integrated GPU?

See, it's not about the time you sit in front of your M1 MacBook and have a nice cup of tea -- it's about the situation where everything goes south and your tools and infrastructures can still have your back

Re: Building the Future of the Command Line

#40
Everyone who builds one of these never fixes the fundamental problem: they don't distinguish between "space" as a character, and the next element in the argv array.

Stop making me have to engage in bizarre escaping rituals and let me just toggle between "string mode" and "array mode".

Post reply on HN