Comment by crabbone
2 days ago
PowerShell is a bad choice for the system shell because it's too complex. I'm not trying to justify all the quirks of Unix Shell, but minimalism is a very important feature of such a tool.
Another important feature of a tool like this is the ability to tolerate errors: I can't imagine a Linux today that would be able to even boot if the shell was extra pedantic about errors. A lot of mostly irrelevant things routinely fail on boot and during normal operation. Stamping them all out is an arduous... well, basically, an impossible task for practical purposes where releases are expected to come on time, where users may manipulate configuration in gazzilions of unpredictable ways.
PowerShell is just another language in the same box with Python, Perl, Ruby and many like that. It's not a good language, if you decided to reach for that box. Probably not the worst either.
System shell, however, isn't meant for writing entire applications. Writing applications with elaborate command-line interface should be left to languages that can properly address this problem. PowerShell is trying to be there, but it doesn't hold a candle to its "older brothers" who can, indeed, design a very robust command-line interface, often using a dedicated library for it.
PowerShell appeals to the novice crowd who are very enthusiastic about automatic checks in their code: the benefits are on the surface, the downsides are difficult to assess. This is in line with other Microsoft software products / languages which target novice programmers by implementing as many as possible of the highly-advertised features without regard to the overall usefulness of the product (think about C# or MS Office suit etc.)
> System shell, however, isn't meant for writing entire applications.
Programmable shells are, in fact, for programming. That posix shell syntax makes it impractical for meaningfully large scripts is something you just accept. And, realistically, it is something you have to accept.
Minimalism isn't why posix shell syntax is bad. For example, awk and jq are minimal but don't make the same mistakes.
Powershell was never designed to be your system shell (Windows doesn't really rely on one) but the main reason it can't be the shell is startup time, which rules it out of wrapper scripts. Its having lots of features might contribute to that but it's not the problem per se (being built on .net is the reason - that and startup time not really mattering on windows). Its lacking the syntax problems of posix shells is very much not a problem. Powershell's error handling is just fine, by the way.
The startup time of even pwsh is too slow to be usable in many scenarios.
PowerShell's not going to be the system shell on your *nix box but it wasn't designed to be. But your posix shell isn't the system shell because it's better. It's pretty much the ultimate expression of worse is better.
That's why there's an industry of alternatives without the faults, such as oil, elvish, fish, nushell. And why awk is so popular.
There are many programs that aren't applications. For example, databases. You wouldn't argue that because you can program in eg. SQL it should be able to make applications with a robust command-line interface, right? Same idea applies to system Shell. Its purpose is to expose the operating system functionality interactively and for ad hoc automation. It is deliberately made simple and therefore incapable of more advanced system programming because complexity creates problems in this particular domain.
For instance, consider that Unix Shell only has one data-type: strings. I believe this was a deliberate decision by its creators (or a stroke of luck). Compare this to languages s.a. original JavaScript with a handful of built-in types, or, even worse, modern JavaScript with user-defined types. Even though the language tries hard to supply default "solutions" to type mismatch errors, it doesn't work well, and sometimes, at all. Unix Shell is inherently incapable of type errors.
While in statically checked programs, or even dynamically checked ones with robust debugging tools types could prevent certain kinds of programming errors, in the mostly interactive programs types make no sense. There simply isn't enough code to generate the kinds of problems types are supposed to solve.
> Minimalism isn't why posix shell syntax is bad.
I never said that.
> Powershell was never designed to be your system shell
Parent wants to replace Linux system shell with PowerShell, that was the reason I replied in the way I did.
> Another important feature of a tool like this is the ability to tolerate errors: I can't imagine a Linux today that would be able to even boot if the shell was extra pedantic about errors. A lot of mostly irrelevant things routinely fail on boot and during normal operation. Stamping them all out is an arduous...
You seem to be implying PowerShell aborts on any error. That's not the case:
https://learn.microsoft.com/en-us/powershell/module/microsof...
No, I didn't imply that. PowerShell introduces many different error modes that aren't possible in Unix Shell because it tries to operate on structured messages, has a type system, has a bunch of built-in functionality for accessing various aspects of the system that in Unix Shell are delegated to external utilities.
My main issue with attempting to replace Bash with other shells is that they're often not installed by default on different Linux flavours and they don't/won't have the same longevity as Bash. Try running PowerShell on a 20 year old Linux system or maybe find out if there's some version issue with running an old script 20 years in the future.
Well said, esp. the last paragraph about the Microsoft strategy.