4 ms·

Is it possible to return structured data in PowerShell from non-.Net languages? I am genuinely asking here, it’s been years since I’ve poked it. If not though t

by donatj 6y ago

Is it possible to return structured data in PowerShell from non-.Net languages? I am genuinely asking here, it’s been years since I’ve poked it. If not though that seems like an enormous stumbling block.

kaba0 6y ago
Well, it can export as json, xml and I’m sure some other formats as well, so in principle it can.
- rbanffy 6y ago
  That sounds interesting, but either programs deal with schema transforms, or we'll have to write a lot of that kind of logic in XSLT or jq (kind of the same stuff we do with cut, sed, awk, sort and grep for unstructured streams). Not sure it's that useful a feature unless the domain of the programs is narrow.
  - kaba0 6y ago
    To be honest, I’ve been thinking about a shell based on the JVM. Especially now with GraalVM, you can have truly polyglot programs running on top of it, with inlinig cross-language boundaries! But of course native code execution should be “bootstrapped” into that world somehow. (Actually, it can use LLVM IR and that as well can run a C function on js objects which is phenomenal, but people do want to run native software from a shell)
    - rbanffy 6y ago
      While you'll be able to invoke methods on returned objects, if you are piping stuff, you'll still need to deal with hammering the output of one program into the input of another.
  - TeMPOraL 6y ago
    I think it could be useful - from PowerShell's perspective, all you need is to wrap your "classical" executables to somehow accept and emit .NET objects, and you can carry on from there. Importantly, no more writing parsers in the pipeline or in your scripts. I could see a whole library of such wrappers being built for common executables (and new popular OSS CLI tools could provide their own wrapper along with the tool).
    - rbanffy 6y ago
      You can wrap your .NET, JVM, Python, Perl or C functionality in a small program that links to the library you want, that deserializes your XML or JSON, reads your command, and acts on the incoming object stream, spitting it to stdout in a neutral, preferably human readable, format that can then be piped into the next command. Oh! Wait! This is what tools like cut, jq, grep, awk, and sed to. And they won't tie you to a certain object model.
      - TeMPOraL 6y ago
        > Oh! Wait! This is what tools like cut, jq, grep, awk, and sed to. Yes! Except, you have to use them to write one-shot parsers that are specific to both what you're piping from and what you're piping to! For n commands you may want to arbitrarily mix, that's n² parsers to write. > And they won't tie you to a certain object model. From the point of view of a system user, tying to a certain object model is a feature. It facilitates commands interacting well with no parsers in between. But even if you don't have a common object model, just wrapping the commands to produce structured output can already be helpful, because the parsers you'll be writing to glue commands will operate on structured, higher-level concepts. It's easier to map between two different representations of what a "file" or "process" is, than it is to manually dig them out of an unstructured text stream. To use a stupid example, assuming hypothetical "kill-and-announce" that echoes a process name and sends a SIGKILL to its PID: ps aux | awk '{ ...extract columns... }' | sed 'rename columns' | xargs kill-and-announce ... Would be harder to figure out than: wrapped-ps | wrapped-kill-and-announce Or even with incompatible object models: wrapped-ps | select Target={id:$_.PID, name:$_.name} | wrapped-kill-and-announce

by donatj 6y ago

kaba0 6y ago

Well, it can export as json, xml and I’m sure some other formats as well, so in principle it can.

rbanffy 6y ago
That sounds interesting, but either programs deal with schema transforms, or we'll have to write a lot of that kind of logic in XSLT or jq (kind of the same stuff we do with cut, sed, awk, sort and grep for unstructured streams). Not sure it's that useful a feature unless the domain of the programs is narrow.
- kaba0 6y ago
  To be honest, I’ve been thinking about a shell based on the JVM. Especially now with GraalVM, you can have truly polyglot programs running on top of it, with inlinig cross-language boundaries! But of course native code execution should be “bootstrapped” into that world somehow. (Actually, it can use LLVM IR and that as well can run a C function on js objects which is phenomenal, but people do want to run native software from a shell)
  - rbanffy 6y ago
    While you'll be able to invoke methods on returned objects, if you are piping stuff, you'll still need to deal with hammering the output of one program into the input of another.
- TeMPOraL 6y ago
  I think it could be useful - from PowerShell's perspective, all you need is to wrap your "classical" executables to somehow accept and emit .NET objects, and you can carry on from there. Importantly, no more writing parsers in the pipeline or in your scripts. I could see a whole library of such wrappers being built for common executables (and new popular OSS CLI tools could provide their own wrapper along with the tool).
  - rbanffy 6y ago
    You can wrap your .NET, JVM, Python, Perl or C functionality in a small program that links to the library you want, that deserializes your XML or JSON, reads your command, and acts on the incoming object stream, spitting it to stdout in a neutral, preferably human readable, format that can then be piped into the next command. Oh! Wait! This is what tools like cut, jq, grep, awk, and sed to. And they won't tie you to a certain object model.
    - TeMPOraL 6y ago
      > Oh! Wait! This is what tools like cut, jq, grep, awk, and sed to. Yes! Except, you have to use them to write one-shot parsers that are specific to both what you're piping from and what you're piping to! For n commands you may want to arbitrarily mix, that's n² parsers to write. > And they won't tie you to a certain object model. From the point of view of a system user, tying to a certain object model is a feature. It facilitates commands interacting well with no parsers in between. But even if you don't have a common object model, just wrapping the commands to produce structured output can already be helpful, because the parsers you'll be writing to glue commands will operate on structured, higher-level concepts. It's easier to map between two different representations of what a "file" or "process" is, than it is to manually dig them out of an unstructured text stream. To use a stupid example, assuming hypothetical "kill-and-announce" that echoes a process name and sends a SIGKILL to its PID: ps aux | awk '{ ...extract columns... }' | sed 'rename columns' | xargs kill-and-announce ... Would be harder to figure out than: wrapped-ps | wrapped-kill-and-announce Or even with incompatible object models: wrapped-ps | select Target={id:$_.PID, name:$_.name} | wrapped-kill-and-announce