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

61–70 of 75 posts

Re: Building the Future of the Command Line

#61

Post by viraptor »

mshockwave wrote: post #39
rektide wrote: post #21

Earlier quoted context omitted.

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…

That's a weird strawman. Nobody aims to take away your standard framebuffer / textmode terminal. It's there for a reason and I don't think this post cares at all about that use case. (Also, you should really invest in iLO or your vendor's equivalent - it pays for itself if you do trips like that)

Re: Building the Future of the Command Line

#62

Post by an1sotropy »

andy81 wrote: post #8
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.…

It feels solved in raw Powershell functions, but running external CLI tools inevitably returns text and ruins the workflow. "Crescendo" has been marketed as a solution and looks cool, but it means relearning the tool or documentation being less useful. The sheer amount of existing time people spent learning arcane git syntax means they're not going to switch to a hypothetical "New-GitCommit" function, even if it acce…

Is this the Crescendo you meant https://github.com/PowerShell/Crescendo ? From your comment I initially thought Crescendo was some separate commercial software.

Re: Building the Future of the Command Line

#63

Post by PurpleRamen »

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

> This trend of "new modern shells" that runs and start as slow as some javascript code (powershell) needs to stop

Who cares, as long as it's not my shell. The old shells and terminals won't disappear, and if some new relevant standard emerges, people will port it.

> People forgot what shells are for, and what scripting is for

Shells are for the people, and scripting might be for people, depending on whether it's a oneshot-script. Maybe you forgot too what they are for?

Re: Building the Future of the Command Line

#64

Post by o-o- »

To me this is just more of the same: added convenience to what we already have. Converting individual commands to TUIs is a step away from the unix philosophy.

I think the future of the command line lies in the direction of flow-based programming and spatial representation of complex commands.

I would like to see a terminal that, as I type, _generates_ a flow-based view of my command. Every command would be visualised as a component: ls, awk, sed... Every |, that I type would append a link and a new component to my flow, and ultimately I would be able to manipulate my flow instead of typing: click the ls component, have it output Creation Date instead of Modified Date, then click the awk component and add another output to a new sed component and so on.

Re: Building the Future of the Command Line

#65

Post by bregma »

It seems to me the solution to the problem posed in the article -- and to the wishes of many of the commenters here -- is to use JavaScript as your shell. The missing piece is an app that presents a text UI with a JavaScript REPL and that renders the DOM inline.

Missing file, device, and information manipulation applications that shell programmers string together would be replaced by JavaScript functions from a library. If you really want JSON, use the JavaScript Serialized Object Notation to serialize JavaScript objects in JavaScript.

Why do people write "what I want is..." articles and comments when they could be writing solutions that scratch their itch and meet their needs?

Re: Building the Future of the Command Line

#66

Post by yaantc »

none_to_remain wrote: post #48

Has anyone done anything around just ... mixing images in with the terminal output? Let's say I wanted to check if I had any old memes lying around my home directory, and have a quick look so I can decide to delete or not. ~$ls *{png,jpg} oldmeme.png ~$imgcat oldmeme.png /----------------\ | oldmeme.png | | appears right | | here in the | | terminal | \----------------/ ~$rm oldmeme.png Terminfo man page shows some e…

Many terminals can do this, see a list based on SIXEL support: https://github.com/saitoha/libsixel#terminal-requirements

This list is not complete, KDE konsole supports this too (and other formats) for example.

Re: Building the Future of the Command Line

#67

Post by mburee »

none_to_remain wrote: post #45
oceanplexian wrote: post #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 i…

What if it tells you to type `man tar`

Then 99% will give up. I mean just try to read the man page of any modern GNU utility, it's so long and filled with options that nobody will ever read that through.

Re: Building the Future of the Command Line

#68

Post by bayindirh »

rektide wrote: post #21
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 r…

> Does start-up time matter?

Yes.

> Who cares?

Me, and my colleagues.

> I have three terminals that have been open for almost a year.

I have 10s of them open at times. Close and re-open at least a dozen ones every day, because what I do requires that.

> Does anything actually require an i5?

Yes "modern" terminals really require some heavy lifting, because "smooth scrolling!"

> Whats wrong with requiring a GPU?

A lot. Showing text shouldn't need gaming level hardware. Then people moan about their battery life.

> Doesnt it get tiring, being so grumbly about other people having fun & doing cool things?

Haha no. Because they do the cool things, and they backtrack and return to roots as they move down the path. Watching this is delightful.

> Do you really think we should do as you say & just freeze time, insist on doing nothing?

Why not try to increase efficiency and try to do cool things without sucking the living light out of our systems, E17 style?

Re: Building the Future of the Command Line

#69

Post by rektide »

nmz wrote: post #33
rektide wrote: post #21

Earlier quoted context omitted.

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…

> 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 have a very hard time believing you are talking about 5 minutes or more per year of wait time. Even two minutes feels suspect.

Personally, kitty or Alacritty or gnome-terminal or terminator or any other graphical terminal I've tried... they are slower to start but it's under 2s, and faster on second load (let's say 1s). It's hard for me to imagine the amount of agony & bitterness, the "I am being deprived of valuable time" for something that costs let's generously say 10 instances of 2s a month, not even a full minute.

And no one is forcing you to switch off what you have. No one is forcing you to stop using serial console or whatever else.

People need to dial down their outrage. This is a huge social problem online. People are vastly overconcerned. Ya'll are not being reasonable. You are being absolutist & maximalists about very particular narrow concerns.

> I care because I expect software to improve, not get worse.

You have an exceedingly narrow & particular view of progress. And it's conservative in that it recognizes & permits no other forms of growth or advancement. You have a high concern that trumps all other concerns & nothing but your own particular view matters.

Re: Building the Future of the Command Line

#70

Post by andy81 »

an1sotropy wrote: post #62
andy81 wrote: post #8

Earlier quoted context omitted.

It feels solved in raw Powershell functions, but running external CLI tools inevitably returns text and ruins the workflow. "Crescendo" has been marketed as a solution and looks cool, but it means relearning the tool or documentation being less useful. The sheer amount of existing time people spent learning arcane git syntax means they're not going to switch to a hypothetical "New-GitCommit" function, even if it acce…

Is this the Crescendo you meant https://github.com/PowerShell/Crescendo ? From your comment I initially thought Crescendo was some separate commercial software.

That's the one.

It's for wrappers around existing CLI tools.

Still feels experimental, but it's a nice idea to get objects from e.g. robocopy without dropping into regex and parsing it yourself.

Post reply on HN