The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
same here, I keep trying to learn it but it just doesn't seem to sink in properly. I did manage to create a small script recently when moving from VS2017 to VS2019, which upgraded all my C++ projects, and tidied up the rest. If only I could expand on what I learned.
I dare to claim, it's a simple matter of getting used to.
You can use .NET objects from PS though. I did this a while ago until MS coughed up Extract-Archive to unzip stuff via System.IO.Compression in a PS script. Not exactly C#, but you still have to learn less new stuff.
Actually, it's the exact opposite of cludgy. All commands follow the same pattern: verb-noun. The parameters all follow the same pattern: -parameter (with maybe additional switches). It really looks like it's a matter of getting used to for you. PS' syntax is pretty different from CMD's syntax, bash's syntax, C#'s syntax, Delphi's syntax (I'm starting to run out of syntaxes I'm really used to here).
PS is, in fact, absolutely self-consistent though.
It's a little like a French car - internally consistent and makes sense if you've never seen another car. Confusingly different for no apparent reason if you compare it to almost anything else. It's almost as if the design criteria was to make it different from everything else.
I spent ages doing the same automation in Python because it was easier and more functional, until I got a job where the locked down environment forced me to use Powershell.
Now I'm nervous about a tool that's installed by default, and which anyone could use.
I disagree with "never seen another car". You're still claiming it's objectively worse. The thing is, I know exactly how you feel! Heck, my muscle memory makes me sometimes work faster when I shell down to CMD and do something there. I know how you feel!
It's just that PS isn't objectively worse, like your french car. It's very different, but it's cool. By now, it's clear that you haven't attempted giving PS a chance. You haven't built complex pipes in Bash & PS (well, you may have in Bash but you surely haven't in PS). You haven't tried reading complex PS scripts.
All that different stuff serves a purpose, it helps getting things done! It's not only internally consistent, it's very logical once you give it a chance. Which you don't.
Speaking of which, why aren't you worried about CMD? It's installed by default, anyone can use it and you sure as hell can, with some effort, do really complex stuff there. Why aren't you worried about VBS? It's ability to call C-like APIs is limited (read: non-existant), but a heap ton of Windows is accessible through COM thus through VBS (well, technically, a COM-object isn't VBS-callable by default, it needs to support IDispatch while COM only requires IUnknown, but MS are pretty good at supporting administration through VBS). Speaking of administration, WMI is installed by default as well.
But it's only PS that worries you. Of course.
PS: at the beginning of this discussion, C# was mentioned. Now it's Python. The thing is, C# is, syntactically, way more similar to PS than it is to Python. This isn't an objective discussion, isn't it?
Try writing decent functions where you explicitly define a return value / object and it gets metamorphasied into a PSObject...
The only way I found to *always* get what you asked for was (for example)
return , VariableContainingObjectToBeReturned
Notice the comma after return and before the variable. Even explicitly casting the varaible to something does not always work...
Another Pet Peave is the fact that if you do not explicitly assign a varible as a return object from a Function (within a function), or pipe a functions return values to null (| Out-Null) it Elephants-Up the expected return value as well...
Who the f*** is General Failure, and why is he reading my harddisk?
Or try to do consistent quoting to pass parameters to an external executable. It's mind-blowing that a fundamental feature for a scripting language - interfacing to other commands - is so complicated. I have in some instances ended up passing parameters to batch files as environment variables. That works reliably.
And then there was the lovely incident with invisible files in an earlier version of PS. I called out to a batch file that created files on a network drive. Unfortunately, when I returned to PS the files were invisible until PS was restarted. Not a happy experience, when the PS was supposed to process backup files produced by the batch file. Caused me a good deal of lost hours - and backups!
And yes, the function return value mystery. Who ever thought that was a good idea ?
I have really tried to like PowerShell. It feels like it should be a major step up from MS-DOS scripting with proper flow control, error handling, etc. But now I try to stay away from it, as it usually ends up eating my time, especially when I need to make it talk to existing scripts.
One success story: I did a PS script that read a file and processed it via a .NET library. That was easy, clear code, and no surprises.