Alias, code completion and nice IDE tooling is the trick, not being stuck in UNIX like CLI mentality.
"Tooling" is a design smell. It's building hacks on hacks to make bad design and lack of understanding somewhat manageable.
For better systems all you need is a shell and a text editor.
That said, we do need a better shell. But definitely one with UNIX and CLI mentality.
Doesn't make "tooling" any less smelly though.
I think even unices have abandoned the UNIX philosophy and turned largely into "there's an app for that", so maybe there's not much interest for a better composable UI.
Why?
Text works. Text is the lowest common denominator for working with data. This is why terminals are still primarily text based. This is also why stdin/out/err are also commonly text based (when the user is expected to view it). Text is simple and easy to parse. Binary data exchange formats (or objects) come in and out of vogue, but text just keeps on working.
Text is a lousy abstraction. It may have worked well 50 years ago when computing was limited to researchers on American universities, but the digital world back then has little in common with ours.
Acting like extending the shell to anything beyond plain text would require switching to fancy new serialisation formats every other year is a red herring. The only thing it takes is admitting a shell isn’t used on typewriters but modern computers, where humans use high-resolution screens and programs can exchange structured data. Everything else follows, and is well suited for standardisation.
But that will never happen as long as grumpy sysadmins insist that cobbling together grep and sed in some arcane incantation is the only thing we ever need.
Simple text-based structured data format (something like YAML) with possibility to embed binary would be the way to go IMHO. And of course one should be able to show graphics in the terminal.
But we're not gonna get it. Open source tol is being rapidly enshittified by corporate EEE with their badly overengineered enterprise crap. :(
I think the lack a structured (text based) format is a definite shortcoming in UNIX. Whitespace delimited lists of strings do get you surprisingly far (although some things are a total mess, e.g. filenames with spaces). But a simple more structured format (e.g. stripped down YAML with maybe non-prefixed lines being a list/iterator of strings for backward compatibility) would make the shell a lot more powerful.
You should be able to include binary in these, but make it render nicely in the terminal (e.g. like browser devtools do).
This doesn't also exclude having binary. And binary data is piped though programs all the time, but it makes including other data painful. Also don't see any harm in being able to show images in the terminal when wanted.
No format will work for everyone and if there was one set format, we’d still have people complaining about how it doesn’t work for their usecase. We'd also have had to (finally) answer the question of how to send the schema with the data.
JSON (and XML and YAML and…) are all methods to try and adapt a text based data interchange format. And they all work roughly the same. You ultimately need some kind of processing library to full read them. But working with the data in any sort of structured context requires specialized tools (ex: jq).
Or you can still grep it, just like I do to manage my tab delimited data, and get part of the way.
I think the chaos of having no standard is kinda the point. Text is the lowest format that is easy for people to work with. We can visually parse it pretty easily, so the tools that support text can be pretty universal. Grep, sed, and awk can do a lot.
But to do anything more, you’re always going to need some kind of specialized parsing, even for tab delimited or CSV data. So, let the terminal work with generic text and be “good enough”.
As an example: you mentioned JSON and YAML and suggested a slimmed down YAML might be more powerful. I deal with columnar data with tens to hundreds of columns and thousands of lines. This wouldn’t work with either JSON or YAML… it’s too verbose. Instead I use (compressed) tab delimited text files for their ease of parsing in many languages. But those won’t work for many other use cases.
With data exchange, there is never going to be one right sized option for all needs. If you can accept that, then the “right” option is to choose none of them.
It's a disgrace that most standard tools don't have even an option for any machine readable output. Or when they do, they are ad-hoc and there are ad-hoc parser tools/flags for those. I.e. you need a lot of (badly implemented) specialized tools.
You can grep, sed and awk YAML all you want. It's just ASCII (or UTF-8) text.
An obvious first tool would be “ls” to produce an easier to parse output. From there, maybe a “grep” to search fields and “sort” to sort by fields.
I guess I can think of many consumers or YAML-like data, but what would some of the producers be?
Many tools don't have "stable CLI interface", which makes them difficult to automate. Apt and git come to mind immediately (although git generally allows specifying formats). Some tools (e.g. ffprobe) support JSON output, which provides very easy "bindings" for it (the actual libav APIs are quite painful).
Unfortunely taken away due to UNIX's free beer offerings.
The arrival of microcomputers, and horrors like Microsoft, were of course a major reason too.
The military wanted (!) to have better/cheaper generations of these computers for Research&Development and for deployment of applications. So it was decided to set up commercial companies: LMI and Symbolics were founded. LMI later sold a license to TI. The market for these machines was high-end: installations could cost anything from $50000 to $200000. In the first years these machines mostly went into military and government projects: military was sponsoring the deployment and first improvements (like the development of Lisp-specific CPUs).
Basically that's not unusual from many other government sponsored research, which later got marketed by a startup.
The Lisp they were using was standardized starting 81/82 (also with the help of Symbolics). This standard then was ported to PCs, Macs, Workstations and Mainframes. The Lisps were available free or commercial (a few hundred dollar to several thousand, depending on the vendor).
The Lisp machines itself remained tied to special hardware and mostly died in the late 80s and early 90s.
Various other free and commercial offerings of Lisp for PCs/Macs/UNIX systems died or survived...
The whole thing was initially financed by a large customer: the government (-> DARPA). This customer demanded commercial versions to be able to use them beyond the few prototypes. Roughly 10k machines (my estimate) were built and sold. At the same time cheaper Lisp systems were developed by universities and commercial competitors. Free / Open Source versions of Common Lisp (the Lisp dialect then also on the Lisp Machines) were developed by CMU (CMUCL), in Germany (CLISP, CLICC), in Japan (KCL), ...
If Microsoft intends PowerShell to be combined with IDE-like features then they sure have a funny way of showing it.
Since when do bash/zsh offer a full sane programming language, not relying in external executables, a full blown language framework ecosystem, ability to load shared objects and importing public symbols as functions, and interoperate with D-BUS (as COM counterpart) as if client bindings were functions (again withouht external processes)?
Could be, but that wasn't the argument. The argument was, that fish has nice auto-completion, and that could be done without $irrelevant_feature_list.
(Also, by the same token, Powershell isn't Windows.)
> stating that Powershell just mimics existing popular bash/zsh means your not aware of Powershell capabilities versus bash/zsh.
So what does it better than bash/zsh in the area of code completion? Simple tab completion? For history, Ctrl-R and F7? Woo-hoo.
> Since when do bash/zsh offer a full sane programming language, not relying in external executables, (...)
Which is completely irrelevant when we are discussing code completion.
Powershell Core is less Windows, that I grant you.
As for code-completion, if you so insist, I don't see anything better on Fish that is so great about it.
I also don't install needless stuff like oh-my-posh, I don't need jumping rainbows and what not on my shell.
And we’re probably not getting there if people insist on cryptic shortcuts instead of semantic naming, just because they’re inclined to type everything out manually. It’s like those developers writing their code in Notepad++ and pretend that’s the way.