What to do instead: use pwsh to completely obviate all these issues.
I won't install a new shell to generate a file list on my CI server. I won't install a new shell on remote machines. Ever.
These structured shells also require commands to be aware of them, either via some plugin that structures their raw I/O output or some convention. They solve _some_ command output structuring but not _all_ the general problem.
So, the answer is good. It promotes the idea that one should be careful when machine parsing output meant for humans.
Uh... that's on you? Why do you intentionally hinder yourself?
> These structured shells also require commands to be aware of them, either via some plugin that structures their raw I/O output or some convention. They solve _some_ command output structuring but not _all_ the general problem.
Okay. It doesn't solve literally every single problem, that is true. It's still miles ahead. And when interfacing with non-pwsh commands, you just fall back to text parsing/output.
Hinder myself? An ephemeral cloud machine would not keep my custom shell anyway. By having to install it _every single time I connect_ I just loose precious time.
I want to be familiar with tools that are _already_ installed everywhere.
The shell is supposed to be a bottom feeder, lowest common denominator, barely usable tool. That way, it can build soon and get stable real fast. That (unintentional) strategy placed it as a core infrastructural piece... everywhere.
Of course, there's scripting and using it on the terminal. But we're talking about scripting, right? Parsing ls and stuff. I want the fast, lean, simple `dash` to parse my fast, lean simple scripts. pwsh is fine for the terminal leather seats.
Who would have thought that little old Microsoft, purveyors of MSDOS CMD.EXE, would have leapfrogged Unix and come out with something so important and fundamental as a shell that was superior to all of Unix's "standard" sh/csh/bash/whatever shells in so many ways, all of which historically used to be and ridiculously still are touted by Unix Supremacists as one of its greatest strengths?
You see, Microsoft is willing to look at the flaws in their own software, and the virtues of their competitors' software, then admit that they made mistakes, and their competitors did something right, and finally fix their own shit, unlike so many fanatical monolinguistic Unix evangelists.
They did the exact same thing to Java and JavaScript, leaving Visual Basic and CMD.EXE behind in the dustbin of history -- just like Unix should leave bash behind -- resulting in great cross platform languages like C# and TypeScript.
Edit: that reinforces my point that taking so long to get there is a hell of a lot better than taking MUCH LONGER to NOT get there.
Maybe bash's legacy inertia is a problem, not a virtue. Is certainly isn't getting a JSON parser in the foreseeable future. The ironic point is that even Microsoft's power shell has much less legacy inertia, and therefore is so much better, in such a shorter amount of time.
> Isn't it ironic that Powershell from Microsoft is so much vastly superior than bash
That said, I think powershell is great for utility-knife uses on windows machines.
I do. I replaced all of the automation scripts on my rpi with pwsh scripts, and I'm not regretting it. Not having to deal with decades of cruft in argument parsing and string handling, learning little DSLs for every command, etc. is so worth it.
Basic features are still lacking from PowerShell that have been in UNIX shells since the very beginning: https://github.com/PowerShell/PowerShell/issues/3316
But hey, that's a fixable problem, right? No, because PowerShell is so suffused with arrogance about its superiority that anything, no matter how simple it was to do in a UNIX shell, has to be cross-examined, re-imagined, and bent over the wheel of PowerShell's superiority, before ultimately getting ignored or rejected anyway.
PowerShell is a language unto itself. It is not a replacement for bash/zsh/etc because nobody who knows the latter well can easily migrate to the former, and that's by design.
Commands and flags are case-insensitive.