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

71–75 of 75 posts

Re: Building the Future of the Command Line

#71

Post by phaedrix »

rektide wrote: post #69
nmz wrote: post #33

Earlier quoted context omitted.

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

I'm guessing you simple don't live in the CLI, i.e. where you're constantly opening new e.g. tmux windows.

Shell startup time _absolutely_ matters.

E.g. slow startup interrupts flow for one thing.

Re: Building the Future of the Command Line

#72

Post by nmz »

rektide wrote: post #69
nmz wrote: post #33

Earlier quoted context omitted.

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

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

Well, the device I was whining about was a pi4 booting from a usb3 hdd (So yes, it will not be instantaneous! because its not an ssd), not an i20 ssd 100 cores device. And I'm not outraged, I looked at it, saw it was a hog and moved on (because again, I care about that stuff). Though, I am slightly outraged at you putting words in my mouth and making a caricature of my self, you don't know me, I don't have an "exceedingly narrow & particular view of progress", I simply know that a device has limited resources, software uses those resources. Allowing software to get less performant, means the system will get less snappy, and that I do hate (mostly because it automatically alerts me of viruses(still have that paranoia) or a runaway process hogging the CPU).

Re: Building the Future of the Command Line

#73

Post by an1sotropy »

andy81 wrote: post #70
an1sotropy wrote: post #62

Earlier quoted context omitted.

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.

Cool, thanks for the info. It is very intriguing, and I admit that until this HN thread I didn't know about powershell, or appreciate this totally different model for how to connect programs together.

This is probably way off-topic now, and my question surely shows my ignorance, but do you know if there precedent for a program, once packaged to work within powershell (or maybe nushell), to use the associated input and output specification as the starting point for making a web interface to the same code (as bridged by a webserver)? Or have I just described .net ?

Re: Building the Future of the Command Line

#74

Post by nmz »

bregma wrote: post #60
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 we need to do is dumb down surgical tools. Anyone should be able to do a coronary artery bypass with just a quick google and some AI assistance. That way your analogy will match the goal of these new shells.

If only there existed some thing, some sort of UI, that basically showed you all you could do with the tool, and there was some sort of checkbox thing where you wanted it to do this and that... gosh, we would be living in the future. not a CUI where you have to memorize --options, but one that has all the options and you pick what you want, and then maybe it prints out the full command you want... we would be living in the future.

(I'm talking about a TUI, this was solved 60? years ago)

Re: Building the Future of the Command Line

#75

Post by andy81 »

an1sotropy wrote: post #73
andy81 wrote: post #70

Earlier quoted context omitted.

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.

Cool, thanks for the info. It is very intriguing, and I admit that until this HN thread I didn't know about powershell, or appreciate this totally different model for how to connect programs together. This is probably way off-topic now, and my question surely shows my ignorance, but do you know if there precedent for a program, once packaged to work within powershell (or maybe nushell), to use the associated input an…

I'm no expert on web dev, mostly working in BI/DBA.

Running commands over WinRM or SSH can return objects of any type from remote machines. In the background I believe it's converting them to serialized CLIXML over the wire.

e.g. $RemotePSVersion = Invoke-Command -ComputerName 'SomeOtherComputer' -ScriptBlock {$PSVersionTable}

Rather than the variable $RemotePSVersion being a string it's an object with the type "System.Management.Automation.PSVersionHashTable", just like if you ran $PSVersionTable locally.

For anything that returns text (e.g. external tools like curl/robocopy) you'll usually convert to an object in your script before further processing. That way it can be passed into whatever next steps in a generic way.

e.g. curl https://catfact.ninja/fact | ConvertFrom-Json | Export-Csv '.\HighlyImportantInfo.csv'

curl https://catfact.ninja/fact | ConvertFrom-Json | Out-Gridview

That's less important when working interactively, but one major difference between Powershell/Bash is the relative focus on scripting vs interactive terminal use.

Post reply on HN