3 ms·

Yeah... shouldn't need to but... there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older

Yeah... shouldn't need to but... there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older cmd-style command line applications. The work around is to write a wrapper in a compiled language and use PowerShell to invoke the wrapper... There's a lot of really cool stuff in PowerShell.

TeMPOraL 6y ago
> there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older cmd-style command line applications. Can you tell me more? So I know what to expect when I hit such issue myself. > The work around is to write a wrapper in a compiled language and use PowerShell to invoke the wrapper... Wonder if you need to really break out of PowerShell for this. Recently when doing some scripting at work, I ended up writing .NET code straight in the script. It looks like this: $someCSharp = @" using System; //... public class Foo : Bar { public override object Baz(Quux arg) { //... } } "@ Add-Type $someCSharp -ReferencedAssemblies C:\Path\To\Some\dependency-I-need.dll This makes PowerShell compile your code into an in-memory assembly and make it available in the session, just as if it was an external .NET type. You could probably make a module out of it. Hell, cmdlets are .NET types underneath, you can make new ones from C#, so you could probably make such ad-hoc .NET classes available as PowerShell cmdlets. I suppose using a proper .NET development environment for this would be more kosher; I arrived at the solution described above because my needs were simple, like binding .NET regex engine to SQLite (to get REGEXP operator in queries), or convincing Invoke-RestMethod to stop checking certificate validity. Still, I love the capability, the fact that I can just drop into C# in the middle of the script. It's one of those things that make me think of Lisp machines and Common Lisp the experience of being able to deeply interact with your environment, and the joy of writing "scripts" that are automatically AOT-compiled (like with SBCL implementation of Common Lisp).

TeMPOraL 6y ago

> there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older cmd-style command line applications. Can you tell me more? So I know what to expect when I hit such issue myself. > The work around is to write a wrapper in a compiled language and use PowerShell to invoke the wrapper... Wonder if you need to really break out of PowerShell for this. Recently when doing some scripting at work, I ended up writing .NET code straight in the script. It looks like this: $someCSharp = @" using System; //... public class Foo : Bar { public override object Baz(Quux arg) { //... } } "@ Add-Type $someCSharp -ReferencedAssemblies C:\Path\To\Some\dependency-I-need.dll This makes PowerShell compile your code into an in-memory assembly and make it available in the session, just as if it was an external .NET type. You could probably make a module out of it. Hell, cmdlets are .NET types underneath, you can make new ones from C#, so you could probably make such ad-hoc .NET classes available as PowerShell cmdlets. I suppose using a proper .NET development environment for this would be more kosher; I arrived at the solution described above because my needs were simple, like binding .NET regex engine to SQLite (to get REGEXP operator in queries), or convincing Invoke-RestMethod to stop checking certificate validity. Still, I love the capability, the fact that I can just drop into C# in the middle of the script. It's one of those things that make me think of Lisp machines and Common Lisp the experience of being able to deeply interact with your environment, and the joy of writing "scripts" that are automatically AOT-compiled (like with SBCL implementation of Common Lisp).