Ask HN: How to effectively learn PowerShell?
I've been looking around for a while now, but haven't really found what I'm looking for. Essentially, what I'd like to use to learn powershell effectively with is a "powershell by example" page somewhere, similar to gobyexample.com or rustbyexample.com where the tutorial encourages active tinkering.
What have you been using to effectively learn the ins and outs of powershell usage?
103 comments
[ 3.4 ms ] story [ 158 ms ] threadI can recommend the PowerShell cookbook too, though. I've been a technical reviewer of the 2nd edition and at least back then it was good :-)
https://www.manning.com/books/windows-powershell-in-action-t...
But it has very nice tab completion with a graphical drop-down :0
ISE has bugs that the CLI doesn't (ex: splats for hashtable arguments used to not work in ISE - I don't know if that is still true, because I gave up using ISE and have only used the CLI for the last 2-3 years).
I don't know about Emacs bindings, but I've tried vim bindings in all sorts of things outside vim, browsers, IDEs, other editors... somehow they never made sense outside of vim.
I think it's this guy: https://www.pluralsight.com/courses/powershell-intro
https://www.pluralsight.com/courses/play-by-play-microsoft-o...
Basically means that if you can spend about one hour every day on the text and exercises in the book you will be able to grasp PowerShell scripting in about a month.
[1] https://www.manning.com/books/learn-windows-powershell-in-a-...
Also "Powershell in Action" by Manning is great to lookup things in detail.
[1] https://leanpub.com/powershell-scripting-toolmaking
https://www.manning.com/books/windows-powershell-in-action-t...
In other words, think of something you want to script, then try to learn how to do that in PowerShell.
What I think you'll find if you try learning something as vast as PowerShell with a general approach is that, whilst you may pick up some decent general habits, you'll also find yourself learning a whole bunch you never use.
Learning PowerShell is different from learning a conventional programming language as each use case you'll have will make use of different commands. It's like having a DSL for each use case. You'll use different commands for Active Directory management, for Azure management, for file processing, etc... As long as you know the basics you can pick up whatever is going to be most relevant for what you do.
https://github.com/mikemaccana/powershell-profile/blob/maste...
Short answer for 'How do I learn powershell?' is:
* Learn 'select'
* Learn 'where'
Once you get those two, and get out of the scraping with sed/grep/awk mentality you now properly get powershell.
I don't know if this information is sensitive, but you probably don't want it there either way.
It acts like Linux touch where if the file already exists it just updates the last modified date
I'm looking for a clean way to install OpenSSH on Windows.
In this regard, few tips:
- Install apps via Chocolatey. If app is not there create a package and maintain it. AU framework makes it one time development event. See this report: https://gist.github.com/majkinetor/a700c70b8847b29ebb1c918d4...
- Your profile is very important. I use profile.d which can be reused easily on all your machines: https://github.com/majkinetor/powershell_profile.d
- Use Powershell Gallery and modules in general. Make module or reusable component for everything. See my work here:
https://github.com/majkinetor/posh
- Make sure you use mandatory cli tools:
cinst conemu less peco sysinternals everything copyq
- Do not use junk GUI editors such as ISE. Visual Studio Code is way better if you have to. Sometimes is OK when debugging. I would suggest vim because speed is of great importance in shell world.
- Follow reddit community and ask questions there rather then on SO which is full of achievement biatches. Redditors will help you for free for the joy of sharing the knowledge.
- Use Github to store all your stuff. Also, in coorporation you can use NAS share to let anybody import stuff from there.
- DO NOT LISTEN naysayers about aliases - use default alises all the time. They are cross-platform and well known and I can go into neurolinguistics of why is it better and easier for the brain but I don't want to do it here. People will certainly whine now but ignore them. DEFAULT (READ ONLY) ALIASES ARE THE BEST. Particularly, if you see somebody does foreach-object or where-object just kill him ASAP.
- Do ALL windows config from Posh. If you don't know ask around. If you are devops dude, you can thank me later, especially when you learn DSC and apply all that knowledge there or with boxstarter.
- If you happen to be locked in older posh use PSReadLine. Keep in mind that $host.Version -lt '3.0' is full of surprises and use latest version if possible.
- Do not compromise with others in coorporation. Ask for script for everything. If sysadmin tells you that server is low on disk you ask for proof in the form of the command you can execute. Ask for invoke-sql when using databases. If you give admin a job to create a IIS site for your web app ask for a script. If you are a project manager, do not close tickets without a script.
- If you monitor vendor excursions in your company infrastructure, ask for transcripipt of ALL operations they do. You will thank me later. Do not sign their work without it.
I can recommend "Windows Powershell In Depth" https://www.manning.com/books/powershell-in-depth-second-edi...
And if you don't enjoy PS almost every single moment you are doing something wrong.
PS: I do not work for Microsoft :) I just think bash and friends are ridiculous in 2017 and honestly a little embarrassing. Do not do that - install Powershell on Linux and Mac if you have to and keep your sanity.
PS2: Somebody will certainly say that ruby/python/whatever is great on linux side. Ignore them. Those are not shell languages (while great otherwise and valuable in your skillset - cinst ruby python etc. is among my mandatory stuff but lets keep perspective here).
Good luck.
That may be the worst advice I've ever seen on how to work with others. It's the PowerShell equivalent of not just preaching veganism but requiring that anyone interacting with you start an organic garden.
But more seriously, anything repeatable easily will do. The problem is, Posh is there on all Windows machines while everything else must be installed (except cmd.exe which should be forbiden IMO). I heave interactions with 100+ engineers of different domains and the only thing that links them is that they all use Windows, even 95% of Solaris/Unix/Linux admins. So Posh is the most practical thing.
If you think reproducibility is bad thing or form of veganism, you should probably find another job.
No, my concern is that if I submit a ticket that says "when I send 65 characters in the Username field I get random spew back, I think you need to be checking inputs better" and get a response of "show this to me with a PowerShell script" then I kick things upstairs with appropriate commentary.
And if the attitude you related in these comments is accurate, I suspect those engineers all have something else in common: working to bypass you as much as possible.
start my-fancy-app.exe; Sleep; [System.Windows.Forms.SendKeys]::Send("A"*65)
makes it way more reproducible and you even quickly get test from there (would do that in AutoHotkey tho for better effect, right tool for the job).
> And if the attitude you related in these comments is accurate, I suspect those engineers all have something else in common: working to bypass you as much as possible.
Actually, its quite the opposite. With that attitude tho, I suspect you get bypasses all the time.
I'll freely confess I'm not up on the current automated testing tools for Windows apps, but I'm hoping they're more sophisticated that "point and pray" keyboard spamming.
My concern with the approach you describe is that there are many categories of application problems that are not reasonably reproducible with a PowerShell script, some that are reproducible only with a sophisticated script, and some that are trivially reproduced.
For the trivial ones that are easily reproduced my feeling is that a quick description going to the developers will probably let them reproduce it more easily in a development environment with appropriate code stops that would be adversely affected by automated keyboard injection directly to Windows. For Windows app development if I put in a code stop to inspect state after each keypress, blowing 64 extra "A"s into my dev environment after the stop is unlikely to be helpful.
For problems that require more sophisticated scripting to reproduce, I'm unconvinced that I want to be requiring that all testers be able to write sophisticated test scripts. Maybe you have a ton of VC money and feel that burn rate isn't relevant, but that doesn't describe everyone. Sure, I want some good automated test scripts and the ability to say "When we run script XYZ with input set ABC it blows up" but scripting reproduction of every scenario? (expletive) no.
Basically you're putting up a sign that says "I don't care what problems you have found, if they can't be reproduced with an automated script I will reject them." That doesn't keep those problems from existing or being found, it just ensures that you don't try to fix them and eventually (if you're still around) it means that you don't hear about them either. That may never cause real problems, or someday you may get an email from Tavis Ormandy or someone you have even less desire to hear from.
Edit: it just occurred to me - basically this is a "captcha" system for bug reporting, but one with the potential for arbitrary puzzle difficulty potentially unrelated to problem severity or reproducability.
Also, I don't have testers, only developers. Testing is the part of the job which is mandatory. Along with some other stuff. :)
Yeah, I don't know. In another comment here I describe how I used to work in a workplace where nobody wanted to learn to use powershell. I was a junior dev at the time and it really wasn't easy for me to convince people of the need to use specific tools. I had enough problems as it was (some folks kicked up a fuss because I didn't smile when I spoke to them; I got a BRF, what can I do?) (and screw that anyway).
So I learned to use psh and used it to make my work easier, and it did miracles for my self-esteem and my self-confidence (which had taken a very bad turn after I first joined that company).
I've also had to bypass thick-headedness in colleagues in other organisations, and even jump through some hoops like connecting to the internet through proxies and restricting what can be installed on a machine etc.
Sometimes, you just have to be flexible, and trying to convince everyone that your way is better is not flexible. If your way really is better- go ahead and do your thing, and ask for forgiveness later, rather than permission now.
But, to be fair- all the stuff you say about using psh to make your job easier, it's all true. invoke-sql in particular, it's gold.
Since I work wiht N other vendors and their engineers on which I don't have much jurisdiction, I just do my stuff explaning why all the time and if they are any good, they will adopt it. If they don't, its typical that they suffer ineficiencies and I show them by doing their work that it can be done better and faster. Top managers notice eventually how efficent things can be. For example, when I want quick metrics on bunch of servers I just invoke flea rather then having to mess with nagios, zabix or friends. Look how readable that is: https://github.com/majkinetor/flea
On my latest project I use powershell to do everything - configure Solaris, install and oracle database, configure and install and manage weblogic servers etc. Powershell is wrapping bash/python/awk/whatever scripts and provides consistent interface for all service operations. Vendor engineers didn't initially want to do it and it turned out that what my company does in 10 minutes they do in an hour. Now they all want it.
The best you can hope in your situation is that the 'truth' will come out from your actions, but you will have to push it also, people are usually enjoying the comforts of technologies that they are experienced with especially with harsh dead lines.
Give it time, and try to get more influental positions. If nothing works, find suitable alternative, posh is not the only stuff in the world. If that is not possible, you don't need job that bad IMO.
I'd be worried about this however:
>> I am head of development in my company. I make standards and learn others WHY. They soon all become groopies
It's easy to get people to agree to everything you say if you're their boss. It's good to keep that in mind, always. For myself, I've had the best experiences and learned the most when I had senior devs who listened and were willing to mentor, rather than impose their will.
Of course, up to a certain extent, if you set up processes in a certain way and then hire people to execute them, and they agree to come onboard, there's no issue of forcing them to do as you say. If they don't like it, they can go somewhere else.
Still, I think the best lesson I got from that job where people didn't want to listen to the junior dev (me) is that you should always be open to advice from all levels in the company hierarchy.
> You should always be open to advice from all levels in the company hierarchy.
I agree 120%. I don't really care what's your position in the company. I am practical person - if you can prove me that I suck I will be happy to change. But I do need proof that new concept works in real world - so many things look good on the paper and you need to digest stuff fully. Currently, my best brainstorm partner can't be lower in the company, but he is driven by pure passion.
I might also mention that I discovered this outsourcer was doing all commands from a root shell, so I now refuse to give specific commands but ask fir the info but I am very deliberate in not giving them the specific commands to get the data.
That said, what I would give to do what you seem to get away with :-)
I get away with it frequently but not always. You can't imagine how many times I got response 'nobody ever asked that'.
What I usually do when that happens is to do one case of their work entirely myself to show a complete working example in real life scenario. That requires certain knowledge about domain in question. I have experience in bunch of tools, platforms and paradigms so I know how to do it about 70% of the time. When I don't, or don't have time for it, I just let it go.
But no matter your position, its very probable that your voice will be listened over that of a vendor consultant so if you can educate your boss with WHY (if not, you could go higher or try to influence someone else who can influence the person you want) there is a chance that your words will be taken before that of the external consultant.
Its nice Windows has finally decided to give their users a real tool to do their work with, and yeah, maybe some of the design (right now) is cleaner than in the traditional shell camps...
But this also sounds like somebody who wants to throw away mountains of expertise around other ecosystems (destructive behavior) just because they like their tool X. What I've never seen a PS user succinctly demonstrate is what new, good ideas PS brings to the table, other than its a better glue language for COM/.NET. And PS being extremely verbose means that frankly, nobody likes it (being verbose is garbage in shell languages - you made the comment that ruby/et. all "aren't shells", however they aren't shells in the same way that PS isn't a shell, they're large, bulky languages that don't take shortcuts).
Considering this is about learning PS, it would be good for a heavy user of PS such as yourself to actually expound on the specific things PS is good at, not the one-trick-ponies like some sql install command.
If you take that "do not compromise, demand a script that proves" attitude this this sysadmin, then this sysadmin will "not compromise" in return, and your code will never be deployed - clearly you're not going to be working on bugfixes, so why should it be deployed?
I'm generally very helpful and my devs generally like me. I take the time to teach when I can and try to learn and understand when I can't. But when someone demands that I write scripts to prove all bugs I find, they can fuck off. I don't have unlimited time - and my duties extend beyond babysitting code. I don't have the close knowledge of the codebase that the developer has. I'm not in the architectural meetings where decisions are made on the internals. I take the code I'm given, and make it live and breathe in the world. I work with the devs in doing this - and if a dev decides that they're too important to be bothered doing legwork in the code that they're the most familiar with, well, fuck 'em. They can sit with their ticket left open.
We're all in this shit together; don't make me do your job with less domain knowledge than you.
What makes you say that ?
> And my devs generally like me.
And half of the world likes Kim Kardashian so what ?
> But when someone demands that I write scripts to prove all bugs I find, they can fuck off
You are not being proffesional then. You demand time of others to do your work, because, hej, you do your best, right ? Your managers decided to leave you out on arch decisions so you think all managers are like that. You extrapolate your slow and unworthy experience to everybody else.
The point is, there are almost no single time events in enterprise. Everything you do, somebody will have to do again, tomorrow, a few days from now, or a year later. So, if you do the things your way, others will have to repeat what you did (or you, or worse, somebody new who knows nothing about it but could get your script with simple Redmine search along with some 'historical records' - read the TMMM and see how communication/tutoring is important - feel free to watch Galaxy Quest later) and that is not a nice thing to do in a company - you are wasting our time, resources, customers etc., on the long run: https://xkcd.com/974/
You can do whatever the fuck you want in the company of your grandpa, but its about time you sysadmins understand that good sysadmining means understanding the code concepts and development tools, and ability to script in the middle of the night. Nobody will ever ask you to write Gherkin tests, Performanse test, unit tests, integration tests, to know OO patterns etc... But in my team I will demand you know how to write 50-100 line scripts. If you can't do that, then you are emberresment for your proffession.
Good time to quote Jeffrey Snover: "GUI-only, Click-Next, no-value-add Admins will be replaced with a new type of Admin - the kind that greet you the lobby".
When you start to experience this paradigm shift, you will soon find yourself thinking about how did you live before that, and maybe even buy me a beer for letting you know that you can improve.
"Do not compromise". That's what "do not compromise" means. If you do your work without getting those things you have demanded, then you have compromised.
> And half of the world likes Kim Kardashian so what ?
My point was that I don't pride myself on being a BOFH. Apparently it's not okay to say "I get along with colleagues", but it's totally okay to say "I make the standards that people in other companies follow like groupies!". Sure you do, mate. Sure you do.
> You are not being proffesional then. You demand time of others to do your work, because, hej, you do your best, right ?
When I say "Hey, devs, this error is appearing in the logs on production - the logs you wrote for the application you wrote - please look at it", the one who is not being professional is the one who says "I'm not going to look at it until you troubleshoot the issue to the degree that you can write a script that replicates the error".
> and ability to script in the middle of the night
You mean the time that devs are never around? It's a bit rich you complaining of sysadmins 'not working after hours'.
> But in my team I will demand you know how to write 50-100 line scripts. If you can't do that, then you are emberresment for your proffession.
a) Even if English is not your first language, if you're accusing someone of being unprofessional, learn to spell the word. It undermines your jibe when you can't spell an insult about professionalism.
b) I can write the scripts. Clearly your troubleshooting is so atrophied that you can't see that I'm talking about the process and incumbent knowledge, not the ability to code. Yes, I write scripts, but no, I don't know what internal code doo-dad you devs thought to change in your last stand-up and pushed through. Why the fuck should the guy who is not intimately familiar with the codebase be the fucker that has to waste their time hunting the snark, then coding up a test for what is, to them, a (somewhat) black box?
> GUI-only, Click-Next, no-value-add Admins will be replaced with a new type of Admin
Again, fuck you too. I live in terminals. You're the lazy guy that wants everyone else to do the work. I'm saying that the person who knows the application should write the replicator script - you're saying the person who reports the issue should write it. God knows how you take a bug report from a non-technical person. I guess it just gets auto-marked WONTFIX.
Certainly you've learned more about the politics than the technical aspects of the industry. "I write stuff the whole country uses!" carries much less cachet when it's a small Balkan state known more for nepotism than for a strong technical sector. Especially when you also say "you can't force anything on someone working in gov", given that government software projects are rarely known for their excellence. But keep on bragging, eventually you'll find someone who listens to the brag rather than the technical merits.
It wants to be a pseudo C# but without being C#. And anyway you can use scriptcs nowadays to write scripts in C# (or even better: .fsx scripts, with F#, which is more succint, less verbose than C#).
The main use-case I have for Powershell is remotely administering Exchange. If I could do that from OSX or Linux, then that would be useful enough for me to spend the time learning it.
I guess you can always do powershell remoting? Apparently it also works from Windows to Linux! https://github.com/PowerShell/PowerShell/blob/866b558771a20c... (got pointed there from this Reddit post: https://www.reddit.com/r/PowerShell/comments/4ziw85/anyone_m... )
Where did that come from? You can instantiate .Net classes from the command line in powershell, but otherwise it's got nothing to do with C#.
Pretty much the only relation between psh and C# that I can think of is that they are two of the three least un-microsofty pieces of software from Microsoft, and they're both really nice to use (the third one being Visual Studio). Other than that, they don't really have anything in common.
True enough, but I'd rather make use of all of the tools I have available on as many platforms as I have available to me so that I don't have to fight to do things with limited tools. GUI is nice, but knowing how the underlying system integrates together through a shell is infinitely better.
> Not crossplatform
Didn't they port to Linux and Mac?
I have to use Windows at work, and do not know Powershell. Several times I've debated learning it, but never put in the effort.
Now I use Xonsh (http://xon.sh/). It is a Python shell - cross platform and similar semantics to bash, etc. I was never a power bash/zsh user (scripting in them is Hell). The nice thing with xonsh is that it is Python. If you want to customize your environment, have complex aliases - well, you just write Python code in your config file.
Learning PowerShell for Windows is the ideal. But xonsh is a good intermediate solution for people who don't want to invest in going all the way.
(To be honest, I'm seriously considering switching to xonsh for my Linux machine - currently I use zsh).
My other worry is that there's going to be some things it's hard to do _on windows_ for any shell that isn't created by microsoft. Which is not the fault of xonsh, or any other alternative shell, obviously- but which might make psh a better deal in some cases.
Can't think of an example though, to be honest :)
I was pointing out that xonsh is a good shell for people who do not want to learn Powershell: people who do not need all the power.
I work on Windows, but I'm not a Windows developer. I do embedded programming, and so am not familiar with most of .Net/COM. I just need to do my work on Windows, and for people coming from the UNIX world, xonsh is a shell that makes life tolerable with minimal learning necessary. Obviously, Powershell is better, but requires a lot more investment.
One of the main benefits of posh is that it provides standards on arguments so that discoverability is easy. Along with that you get automatic tab completition for everything, module autoloading and nice stuff such as proxy commands, JEA and other great stuff not avaialble in alternatives. The other one is that nowdays many tools expose automation via powershell modules - sql server, visual svn, chocoalatey, vmware, etc. just to name few - so all that power seems wasted with xonsh on Windows. Not to mention wmi, COM and other nastier stuff becomes way more problematic then it needs to be. Good luck driving Excel for example.
There was similar attempt with Ruby (https://github.com/adamwiggins/rush) - but it failed because you do really need a special language for shell. Its pitty Xiki (http://xiki.org/) didn't become mainstream talking about Ruby.
Whitespace semantics also look like troublesome in the shell context and I guess in some more serious usage ambigious stuff like ls -l may become problematic and hard to detect source of bugs.
On the other hand, it rewards with better Python knowledge which is always good.
Well, none of the UNIX shells are comparable to Powershell. That's why this is a nice in-between solution. A way to have a UNIX like shell on Windows, without the need to learn a new language if you already know Python.
>Whitespace semantics also look like troublesome in the shell context and I guess in some more serious usage ambigious stuff like ls -l may become problematic and hard to detect source of bugs.
Been using it for a few months. So far, not a problem. The biggest headache is that "dir" is a reserved keyword in Python. Not a problem: I just made 'ls' an alias for it.
The only real problem is that Windows has case-insensitive environment variables, but xonsh makes them case-sensitive. This is fixable, and they'll probably fix it some time soon.
Yes there is one, Powershell :)
Thx for detailed report by the way. I hope the project will get mature and adopted.
When searching for tutorials online, "the scripting guy" was useful, but more importantly I make sure to search for powershell v5, v4, or v3 tutorials. - There are lots of "old" tutorials, but I think there were major changes between Powershell v1, v2, and v3, so I try to avoid those, especially regarding modules
[1] https://mva.microsoft.com/en-us/training-courses/getting-sta...
Start small, with ls, cp and cat, and don't force the pace. psh is a shell first and foremost- a shell with a very nice language, but a shell all the same. So get comfortable using it as a shell.
First thing is to create your $PROFILE. Google for an example and see if you can edit it to suit you. Then get chocolatey, PSCX (psh community extensions), posh-git and vim, and get used to doing most of your work on the command line (like you'd do with bash, on Linux). See what tasks you can automate by writing a few short scripts- very simple things at first, like copying and renaming files, setting up directory structures and so on, then progress to processing xml and setting up scheduled tasks, and sending email, setting up credentials etc. After a few months you'll find that you can wean yourself of windows GUIs for most of your everyday tasks and probably all of your not-so-everyday ones.
psh being a command-line tool, it's far easier to learn it like that, than trying to learn the language first. You can learn the basics of the syntax allright, but there's a bazillion commandlets that you will never be able to remember, unless you use them in your everyday work, and incorporate in your scripts, and those commandlets are often integral to the use of psh. Basically, you can't separate the language from the use of the shell, so you shouldn't try. Learn them both at the same time.
Here's my personal example: I learned psh to avoid the long rdp queues in a past workplace.I guess that company didn't want to shell out for more windows server licenses and so there was a limit to the number of people who could rdp to a server at the same time- just two or three people per server. So there was always a bit of a queue and I often had to wait between a half hour and a couple of hours before I could get a slot. Or someone would go for lunch and forget to log out, and you had to kick them out and it was generally a big drag.
At some point I started using psh as my windows shell, and then I found out about windows remoting [1], which sounded a lot like ssh on Linux- basically, it lets you open a shell on a remote computer. Next time I had a slot on a remote machine, I enabled remoting and suddendly I could do all the work I needed on the command line, while everyone else still had to wait in line for an RDP slot [2]. Needless to say, this made my life and my job a hell of a lot easier, not to say pleasant (I might have had a few smug smiles on my face, at times).
I'll note there was only one thing I couldn't do remotely: running a proprietery installer for the company's platform, that only had a gui and no command-line options. Everything else, including a whole bunch of SQL stuff, I could do it remotely, on psh [3].
All this naturally pushed me to do more psh scripting, as it was easier to run a script than key in a dozen commends on the command-line. So I left that job feeling very comfortable with powershell, and although I didn't quite have to use it that much in any other job since, I still use it as my primary shell at home.
____________________
[1] I think it started with this article, whose title immediately caught my attention:
http://www.howtogeek.com/117192/how-to-run-powershell-comman...
[2] Noone else cared to learn powershell. I did ask. They said they didn't want to have to learn a new programming language. To be fair, I never explained my remoting setup to anyone, because they would probably tell me to stop using it (I was just a junior dev at the time). Note also that I never enabled remoting on any of our public-facing servers, just in case there was some vulnerability that could be exploited....
RDS CALs aren't cheap, but they're a one time cost and insignificant compared to the cost of staff sitting around waiting for RDP sessions to free up.
I spoke up about those inefficiencies very early on, but I was very inexperienced at the time and, to be honest, I had no idea how to properly communicate this sort of thing, so I never got anywhere. I only managed to come across as snotty and get a reputation as a trouble maker.
After that I just kept to myself and focused on getting some experience with C# and learning psh and so on, generally learning as much as possible until I felt confident enough to look for a better job- which I took as soon as I found it.
Generally, I was really unhappy in that company, but at the same time, exactly because I had to jump through hoops and learn how to automate my work, I taught myself a whole bunch of stuff that were very useful in my next job (where, btw, I had a great mentoring relation with my boss). So it all turned out alright.
https://www.youtube.com/playlist?list=PL6D474E721138865A
Hell, I even found a C# code snippet and was able to add into a Powershell string, then add this as a C# type definition, and Powershell compiled it to an assembly and then loaded it as an instance of a Powershell object.[2]
1. http://www.leeholmes.com/blog/2009/01/19/powershell-pinvoke-...
2. I found how to do this here: https://blogs.technet.microsoft.com/stefan_gossner/2010/05/0...
Here's a list of likely Powershell submissions:
https://hn.algolia.com/?query=powershell&sort=byDate&prefix=...
Seems like a pleasant platform. Thanks for this thread.