3 ms·

It is worth noting that this article is from 2017.

by rkangel 6y ago

p_l 6y ago
Which is over 5 years after Powershell became common.
- INTPenis 6y ago
  Yes but some would argue Psh didn't become useful until release 6 in 2018.
  - p_l 6y ago
    That would be... an opinion. Not very grounded one unless one's whole base for it was "I couldn't use it on Linux".
  - indymike 6y ago
    As long as I have to write C# wrappers to launch commands like I would in unix with xargs or parallel in PowerShell it's still not the ticket.
    - TeMPOraL 6y ago
      You shouldn't need to, unless your PowerShell installation doesn't support Invoke-Command, or ForEach-Object -Parallel...
      - indymike 6y ago
        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).
    - p_l 6y ago
      And neither of those are native parts of shells but external applications, dare I say, just like the C# wrappers. (Especially parallel, since it's nowhere close to default install, and has very pesky license notice). OTOH, PS 7.0 added ForEach -Parallel
      - indymike 6y ago
        Yeah, but & is a thing and will do the job nicely as long as you don't try to pipe output to the same file... also, you can invoke pretty much any command with xargs... the issue was escaping escaped stuff with PowerShell. Hopefully things have gotten better.

It is worth noting that this article is from 2017.

p_l 6y ago

Which is over 5 years after Powershell became common.

INTPenis 6y ago
Yes but some would argue Psh didn't become useful until release 6 in 2018.
- p_l 6y ago
  That would be... an opinion. Not very grounded one unless one's whole base for it was "I couldn't use it on Linux".
- indymike 6y ago
  As long as I have to write C# wrappers to launch commands like I would in unix with xargs or parallel in PowerShell it's still not the ticket.
  - TeMPOraL 6y ago
    You shouldn't need to, unless your PowerShell installation doesn't support Invoke-Command, or ForEach-Object -Parallel...
    - indymike 6y ago
      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).
  - p_l 6y ago
    And neither of those are native parts of shells but external applications, dare I say, just like the C# wrappers. (Especially parallel, since it's nowhere close to default install, and has very pesky license notice). OTOH, PS 7.0 added ForEach -Parallel
    - indymike 6y ago
      Yeah, but & is a thing and will do the job nicely as long as you don't try to pipe output to the same file... also, you can invoke pretty much any command with xargs... the issue was escaping escaped stuff with PowerShell. Hopefully things have gotten better.