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

51–60 of 75 posts

Re: Building the Future of the Command Line

#51

Post by dotancohen »

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

I dream of stdmeta for e.g. header lines:

https://unix.stackexchange.com/questions/197809/propose-addi...

I see much potential in adding stdjson as well, but I do caution against opening the floodgates to std* being implemented for every pet format and insignificant corner case.

Re: Building the Future of the Command Line

#52

Post by dotancohen »

an1sotropy wrote: post #15
scj wrote: post #13

Earlier quoted context omitted.

The intent is that standard tools would output alternative formats.

Right; every file is just bytes but we get a lot of mileage out of libraries like libpng that parse those bytes into usefully structured info. And I was pondering what more could evolve to parse info from the command line. I think stdjson is insane yet awesome to ponder.

I agree that a standardized structured format would be awesome, but I'm not convinced that JSON is it. And there should _not_ be more than one.

One thing that I do like about JSON is that it is ubiquitous - and that makes up for a lot of its other faults. But I would like to see proposed use cases that JSON would not support beforehand, to clearly define where the limitations are, and what limitations the community is willing to accept.

Re: Building the Future of the Command Line

#54

Post by dragonelite »

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

Tui example looks really nice would be cool if someone made something like that as a markdown previewer without having to jerryrig it to a browser.

Re: Building the Future of the Command Line

#55

Post by csande17 »

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…

On macOS, iTerm implements this, and they even provide a command called imgcat that works like you describe: https://iterm2.com/documentation-images.html

Kitty provides a similar but incompatible protocol: https://sw.kovidgoyal.net/kitty/graphics-protocol/

Re: Building the Future of the Command Line

#57

Post by RedShift1 »

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

Count me in this camp as well. The hardware guys did their jobs, our hardware as now faster and more power efficient that anything that came before it. But now the software guys are letting us down making everything slow again.

Re: Building the Future of the Command Line

#58

Post by kwhitefoot »

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…

Terminology can display images and video inline.

"This is an EFL terminal emulator with some extra bells and whistles such as the ability to display in-line images, video and even play music files, background images, videos, Z-Modem like sending (e.g. SSH into a server and use tysend to send a file back to the local terminal), GPU Accelerated rendering (optional - just set the EFL Elementary toolkit engine to use OpenGL) and much more."

https://github.com/borisfaure/terminology

Re: Building the Future of the Command Line

#59

Post by nishs »

scj wrote: post #13
BirAdam wrote: post #12

Earlier quoted context omitted.

You can always just use JQ. Additionally, as JSON is text, you can use awk/sed/grep and so on.

The intent is that standard tools would output alternative formats.

The tool should instead provide an `--output=` flag, where is one of text (default), json, xml, etc.

Re: Building the Future of the Command Line

#60

Post by bregma »

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.
Post reply on HN