The UNIX philosophy was to write a solid system by taking most of the hard problems in kernel space and kicking them into user space. This is not a slur, this is a description. Especially at the time, it wasn't at terrible solution. I kind of think of it the same way as many programming languages have observed that "the standard library is where things go to die"; the code in a system that is hardest to change, well, it doesn't change! So any bad decision that ever gets in there is almost permanent. Part of the reason UNIX won is that it enshrined fewer bad decisions in the kernel than its competition did. I think you could even argue it had more bad decisions overall than its competition, at least towards the beginning; it's just that far fewer of them were enshrined in the kernel.
This is also the philosophy of the pipe. It disclaims all layout and moves that responsibility on to the consumers. There is no "shell language", at all. This is, simultaneously, a big strength and a big weakness.
One aspect of that is precisely that the strength of this approach tends to inhibit anyone who tries to beat it with something like Powershell. All Powershell had to be was better than any shell on Windows. This was not hard. For something like Crush, to take off it has to be better than any existing shell on UNIX, and as annoying as unstructured pipes may be, the ecosystem as a whole still has a lot of positives about it, because it's been tuned for 50+ years. It's going to take a lot of work to match that, and so far, it doesn't seem like any of these projects are achieving take-off velocity.
Arguably, the best thing to do would be for all these projects to get together and try to define a standard UNIX-level non-textual rich serialization of some sort, using lessons from Powershell and arguably things like D-Bus to do it, because none of these projects individually seem to be on a success trajectory.
Who cares about "taking off"? If it's useful for 10s of users, it has taken off.
Consider xonsh (https://xon.sh/). I don't think it will ever be "mainstream" the way bash or zsh are. I doubt it will ever come preinstalled in any major Linux distribution. But it's used by enough and has enough momentum that I don't worry it will die. That alone is enough for me to use it as my primary shell. I don't care that xonsh will never "take off".
It doesn't have to be the goal of the project or the author, but there are real advantages to achieving a takeoff, even to the users of a product.
What is the one thing that GNU ls does well, by the way?
Backwards compatibility with itself, probably.
If you came away from my post with the impression that this system produces a lot of elegant software, well, I must have screwed up in my writing somehow. What it produces is bodges upon bodges, which are then polished by years of ramming into the corner cases and putting in another bodge to fix them. There is actually something to be said for this design methodology, and it's not all bad, but it rarely produces elegance.
Now, at least GNU ls doesn't send or receive email or something. A quick scan of its man page doesn't show many any features grossly out of line with its primary task. But yeah, it has a lot of features for sure, many of which nominally overlap with tasks that could be done by other tools (sort, ignoring backups, -D ("generate output designed for Emacs' dired mode", lol), quoting styles...).
I feel much the same way about Python. Very little of its philosophy expressed back around 2000 or so is in effect today. And there's no one release you can point at and say, "this is it, this is when it stopped being simple", yet, clearly, today it is no longer simple.
The "UNIX philosophy" gets cargo cult by younger generations thanks to a couple of statements in a few worshipped books, yet there is hardly any UNIX clone post V6 where it was actually followed upon.
Windows wasn’t designed around the command prompt, it wasn’t designed around shell utilities. When I call “cat”, it’s not important that I’m writing those three letters, they are a library way of calling a set of file open/read OS functions. When I write “ping”, it’s not the ping tool I care about, it’s the network api calls it does behind the scenes. The Unix/Linux shell is then seen like a “Python standard library” of ways the user can control the OS, and it’s a hugely inconsistent, undesigned, ad-hoc agglomeration of names and parameters and bodges, which cheats out on dealing with the complexity and instead offloads that straight on to the user in a user hostile way.
What powershell tries to do for Windows is make a somewhat designed, consistent, and more user-approachable set of wrappers around the Windows OS system calls, along with guidelines and support for vendors to build in that style, a human interface that is introspectable, built to be programmable, but still composable and modular.
The objection that trying to do such a user-focused thing on Unix makes a “useless” system is weird because that - a user interface to tools/library of OS call patterns - is what the shell is. In what way is “resolve-dnsname” pretending to be one with the system that dig and nslookup aren’t? They’re names which trigger a pattern of network traffic and show a result. In what way is piping text from dig to sed “real” and piping resolve-dnsname to format-list “pretend”?
In what way is running “docker compose” from sh real, but running it from zsh is pretend?
In what way is it a better design to have (a pile of shell tools and Python library wrappers and Python wrapping shell tool calls), instead of (a Python based shell with transparent shell tool calls)?
Like, “I want what I’m familiar with, too many things to relearn”, or “too many things are awkward in this approach (cough PowerShell)” are reasonable objections, but “trying for a more consistent, more human friendly, interface with more high level language constructs at one’s fingertips makes a thing useless to me” feels heel dragging or Stockholm syndromeish. Presumably you don’t object to there being a choice of multiple command line tools to do a task? Why object on principle to a choice of other OS “front end experiences”? Is there any version of things which you can imagine as being both “better” (less arbitrary and inconsistent than shell) and “not pretend”?
> “The point of shell is that it interoperates freely with all programs and all programs share a language.”
What language? Some treat piped bytes as bytes (e.g. piping a binary file), others as ASCII, others as UTF-8. All support different parameter options, names and values and ways of specifying them. Many handle output formatting in different ways, many trigger internal states from environment variables. If the point is a common shared language, the point doesn’t seem to have been achieved from a user perspective. And if the point is that “I have to suffer a system that’s tied to a shared language with an AIX box in a bank basement last touched by a human in 1997” the point is a bad one. I use my computer a lot more than I use AIX and I have more computing power to spare on human comforts and conveniences.