While I really would like UNIX shells to get the ability to pass structured data, one problem is that most shells out AFAIK there don't give the ability to pass structured data natively.
For these structured shells(like Powershell, elvish, Nushell) to succeed, they should...
* have a spec on how to pass structured data from a native executable (without function calls like 'from-json')
* implement some structured data functionality in all GNU coreutils at the very least
* and push the 'structured shell evangelists' to implement these schemes on other programs.
That is unlikely to happen in PowerShell because the structured data is .Net objects. If you are writing a C# cmdlet, it runs in the PowerShell executable process. That is, the output is not structured text it's live state, open file handles, methods, in-memory structures, whatever you want. You aren't going to do that from a native command running in a separate process returning data through stdout without serializing it - and then you're back to convertfrom-json as far as it matters.
> For these structured shells(like Powershell, elvish, Nushell) to succeed, they should...
For PowerShell to succeed, Microsoft should rewrite all the GNU coreutils? Did you see the months of outcry when Microsoft used the four characters "curl" in PowerShell? You reckon anyone is going to want unilaterally rewritten coreutils? From Microsoft?
Microsoft should stop on their development of a completely new tool and hobble themselves to the constraints of the stuff they're trying to replace, controlled by people they're in competition with? Unlikely fantasy world.
Firstly, I wasn't writing the comment specifically about PowerShell - it was just a rant about the structured shells.
> That is unlikely to happen in PowerShell because the structured data is .Net objects.
Isn't that an implementation detail?
> You aren't going to do that from a native command running in a separate process returning data through stdout without serializing it - and then you're back to convertfrom-json as far as it matters.
Not having to write 'convertfrom-json' IMHO is a big improvement. 'ls[0..3]' is much more convenient than 'ls | from-json[0..3]'. (Imaginary syntax, BTW.)
> For PowerShell to succeed, Microsoft should rewrite all the GNU coreutils?
I wasn't really talking about PowerShell either, but well, yes I do think that for PowerShell to succeed there should be support for native PowerShell in 'ls', 'find', 'grep', etc...
> You reckon anyone is going to want unilaterally rewritten coreutils? From Microsoft?
It doesn't to be 'rewritten', it just have to gain support. I don't think that a set of patches that adds a new output format will be that problematic. And, one doesn't have to use PowerShell support if one isn't using PowerShell.
> Microsoft should stop on their development of a completely new tool and hobble themselves to the constraints of the stuff they're trying to replace, controlled by people they're in competition with? Unlikely fantasy world.
Er... you know - nobody said that one should replace your bash with Powershell. If you decide that the 30-year-old-unable-to-handle-spaces-in-filenames-by-default script language is fine for you, then you can keep using bash. They're not EEEing...
BTW, checkout elvish shell, since it's not from MS and it has some good ideas. You might like it if you're just hating PowerShell b.c. it's from Microsoft.
> > That is unlikely to happen in PowerShell because the structured data is .Net objects.
> Isn't that an implementation detail?
Arguably, but I don't think so. They stopped writing a language spec at version 3, but the spec which exists[1] says on page 1 "Windows PowerShell is built on top of the .NET Framework common language runtime (CLR) and the .NET Framework, and accepts and returns .NET Framework objects." so that's in the spec. Either way, there is only one PowerShell implementation to speak of so if you want GNU utilities to emit structured objects to PowerShell without going through the serialization to JSON/CSV step that you want to avoid, you will practically have to add interprocess communication into the running process of a managed language and emit .Net objects, and that will be a difficult push.
If you built an implicit decode-from-JSON step into running native cli commands, as Invoke-WebRequest has for talking to REST APIs, you could get more convenient syntax but they will forever be second-class citizens. They won't follow the Get-/Set- verb naming scheme, they won't be built to take pipeline input or handle command line parameters in the same way, they will be limited to only output which can be serialized to text.
By the time you've updated `ls` to read [System.IO.DirectoryInfo] through stdin, detect if it's running inside PowerShell and return serialized [System.IO.FileInfo] output to stdout, and rewritten PowerShell to auto-convert output like this to objects, you may as well have used Get-ChildItem instead.
> I don't think that a set of patches that adds a new output format will be that problematic.
For these structured shells(like Powershell, elvish, Nushell) to succeed, they should...
* have a spec on how to pass structured data from a native executable (without function calls like 'from-json')
* implement some structured data functionality in all GNU coreutils at the very least
* and push the 'structured shell evangelists' to implement these schemes on other programs.