6 ms·

Powershell does take a while to become fun. Key thing (I assume you know this?) is that while bash pipes a string-stream, powershell pipes a stream of structure

Powershell does take a while to become fun. Key thing (I assume you know this?) is that while bash pipes a string-stream, powershell pipes a stream of structured objects. This is powerfull but also quite confusing sometimes. The other key thing is that Powershell has straight access to the whole .NET framework (or whatever its called these days) except you've gotta switch to .CallSomeMethod(with,brackets) syntax for that. This list of common Gotchas on SO was useful to me: https://stackoverflow.com/a/69644807/22194 https://stackoverflow.com/a/69644807/22194 Powershell is quite good at working with CSV: Import-CSV, Export-CSV, Where-Object, Select-Object, Sort-Object, Group-Object etc become quite handy when used together.

nathanaldensr 3y ago
Windows PowerShell targets the old .NET Framework, which is Windows-dependent. Modern PowerShell targets .NET [Core] and is cross-platform. Also, it's not true that you need to use "CallMethod;" PowerShell can invoke methods with syntax nearly identical to C#'s.
- tempaway41114 3y ago
  edited my comment above for clarity - I didn't mean literally CallMethod, I meant that normally Powershell uses 'shell' syntax where parameters are separated by spaces Do-Something withthisfile.txt -AdditionalParam 23 But if you're calling a .NET method you switch to C# syntax with brackets and commas: $str.Trim('-') I mean thats kindof obvious but its one of the many things that makes Powershell's learning curve a little steeper. But hey we can always just google it which is par for the course anyway nowadays
  - csydas 3y ago
    Not sure, but I think the above commentor was meaning to tell that powershell supports .NET reflection. That is, while you can call .NET methods on objects like: $Object.SomeMethod('arguments') You can also do: [Namespace.ClassName]::SomeMethod('arguments') And your Powershell scripts can even save you a lot of typing with the ```using``` function of Powershell to load namespaces: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_using?view=powershell-7.3 https://learn.microsoft.com/en-us/powershell/module/microsof... Edit: As to why you would want to do this, usually it's because you want to do some scripting but you need to pull data out of some .NET application or out of Windows and there isn't a fully fleshed out cmdlet built for it. In a pinch, you can usually just use reflection to get it. For example, I needed to pull data from a Shared Outlook calendar that not everyone had access to and then do some date-math to share a time-sensitive schedule with a team living in quite a few timezones. Reflection to load the necessary Outlook and MSExchange elements, then the rest in Powershell. Now I have a script that is easy to pass around, can do this if I'm unavailable, and we can easily add/remove time zones/persons, and it just needed 5-ish lines of .NET inside of the Powershell script.
    - jiehong 3y ago
      Or if you just want to parse date time in a script.
baz00 3y ago
I've been writing powershell for 5 years and I'd rather slice my balls up with glass and dive into the red sea. How much longer before it becomes fun?
- tempaway41114 3y ago
  At least another 5 years I'm afraid
  - baz00 3y ago
    My poor balls
pjmlp 3y ago
Not only .NET, any COM library or DLL as well.

nathanaldensr 3y ago

Windows PowerShell targets the old .NET Framework, which is Windows-dependent. Modern PowerShell targets .NET [Core] and is cross-platform. Also, it's not true that you need to use "CallMethod;" PowerShell can invoke methods with syntax nearly identical to C#'s.

tempaway41114 3y ago
edited my comment above for clarity - I didn't mean literally CallMethod, I meant that normally Powershell uses 'shell' syntax where parameters are separated by spaces Do-Something withthisfile.txt -AdditionalParam 23 But if you're calling a .NET method you switch to C# syntax with brackets and commas: $str.Trim('-') I mean thats kindof obvious but its one of the many things that makes Powershell's learning curve a little steeper. But hey we can always just google it which is par for the course anyway nowadays
- csydas 3y ago
  Not sure, but I think the above commentor was meaning to tell that powershell supports .NET reflection. That is, while you can call .NET methods on objects like: $Object.SomeMethod('arguments') You can also do: [Namespace.ClassName]::SomeMethod('arguments') And your Powershell scripts can even save you a lot of typing with the ```using``` function of Powershell to load namespaces: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_using?view=powershell-7.3 https://learn.microsoft.com/en-us/powershell/module/microsof... Edit: As to why you would want to do this, usually it's because you want to do some scripting but you need to pull data out of some .NET application or out of Windows and there isn't a fully fleshed out cmdlet built for it. In a pinch, you can usually just use reflection to get it. For example, I needed to pull data from a Shared Outlook calendar that not everyone had access to and then do some date-math to share a time-sensitive schedule with a team living in quite a few timezones. Reflection to load the necessary Outlook and MSExchange elements, then the rest in Powershell. Now I have a script that is easy to pass around, can do this if I'm unavailable, and we can easily add/remove time zones/persons, and it just needed 5-ish lines of .NET inside of the Powershell script.
  - jiehong 3y ago
    Or if you just want to parse date time in a script.

baz00 3y ago

I've been writing powershell for 5 years and I'd rather slice my balls up with glass and dive into the red sea. How much longer before it becomes fun?

tempaway41114 3y ago
At least another 5 years I'm afraid
- baz00 3y ago
  My poor balls

pjmlp 3y ago

Not only .NET, any COM library or DLL as well.