Earlier quoted context omitted.
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 serializi…
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…
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.
See https://news.ycombinator.com/item?id=12319670 / https://github.com/PowerShell/PowerShell/pull/1901 for the kind of hassle that just being microsoft near Linux causes. Unilaterally patching coreutils for Microsoft-specific behaviour will have an apoplectic body count associated with it, I reckon.
[1] https://www.microsoft.com/en-us/download/details.aspx?id=363...