You know, and I apologize for giving you zero day notice that I wanted to have us wear silly things. It's

a, you know, we make it work. That's

the thing about PowerShell. It's like we're professionals, right? But we also have a little bit of fun. PowerShell's fun. We're trying to balance a little bit while we're here today on this PowerShell holiday episode. But let's get started, man. We want to talk about some stuff today, and that's including the AST or the Abstract Syntax Tree, which is some advanced stuff, but I kind of want to build into it. You're actually going to give us a little demo. I may have gotten a little teaser and it was very enlightening. I'm actually pretty stoked before we've, we've been talking for an hour before we went live. We pair programmed. Can you confirm?

You can certainly call it that. There was two of us. There was

two of us. And you know, one of us did the heavy lifting. I'm not going to say who it was. You can guess. Maybe the person is doing a demo, but maybe the person is just sitting here talking, saying nonsense to the camera, one of us. But I want to talk about Script Analyzer a little bit because I saw your blog. I saw you've been writing about it. I know that you're an advanced PowerShell user. And when I say this, don't let Gilbert fool you. He sounds normal, right? You can listen to him. You're like, oh, I can relate to that guy. He's an abnormal. He is when it comes to PowerShell. He is good with it. I tell you what, I'm watching him plug away. And I think you've had some opportunities for some advanced use cases. And I think you're sort of going to give us some enlightenment on where you are with things with that. But let's just get started. What is script PS Script Analyzer? What is that?

So that is the native PowerShell command or module that allows you to lint your code. It can catch when you have bad syntax. It can help you improve some of your code. So if you use certain commands that you maybe shouldn't, it'll kind of capture that. And script analyzer for the most part has been pretty stable. It's gotten some recent updates, but it's very much the rules that are out there are sort of generic rules. And so I have seen folks write custom script analyzer rules for themselves. So the one I came across was by Jordan, Jordan Boreans. And what I didn't see was a good way for you to be able to share that, especially if you're talking about across your own, all your code repositories, or potentially like across your organization. Like once you write a rule, how do you, how do you get that everywhere? So that's what that blog covers. I came up with this kind of term that I call the proxy module that basically allows you to share your script analyzer rules as a module. And then it basically hands off the actual rules using the proxy.

Okay, so let me break this down a little bit. So people out there who've used VS code, they may have seen some PS script analyzer not even really known. Is that fair to say?

Totally. Yeah,

because there's some integration there where like any code you write, let's say you initialize a variable and never call it again, like you get some red text. That is PS Script Analyzer, right?

Correct. Yeah. So if you get red text or yellow text, that's basically PS Script Analyzer under the hood. But you can also, another thing I want to call is you can also call Script Analyzer directly. And so for a lot of folks, that's kind of the only way they would do it. And now with it integrated in VS code, it's, it's, it's automatic. Right. And so that's, this is kind of the power of it. It's like, you already have the thing there. How do you, how can you leverage it for, for everybody?

Yeah. Cause I think what we say in VS code is just the helpfulness of making it available to us and present without us having to know it actually exists. But you can kind of leverage that knowledge and end up using it with some cool projects, right? You can go from just an individual trying to write somewhat clean code that works. VS Script Analyzer is good for that, helps you avoid some kind of common pitfalls. But also as maybe like a project maintainer or someone who's more advanced in their PowerShell journey, you can use it for some more customized things where you can kind of create your own rules. And that's sort of the space you're in a little bit is where you were able to kind of create some of your own rules and sort of distribute it in your org kind of thing. Yeah,

definitely. You can imagine, you know, there's some consensus around certain rules right but there's definitely going to always be you know a personal preference or a or a maybe an org wide kind of maybe mandate or something that says like here's how we should write this code um by, you know, this is a good way to make it so that that happens automatically. Script Analyzer has the ability to auto fix certain things. So if you can plug into it correctly, you can actually have it fix stuff for you. So it's handy. Nice.

Yeah, it's a pretty cool blog. I'll have a link to it in the show notes if you want to dive a little bit deeper. But that's what I really enjoy about PowerShell. The sort of PS script analyzer thing represents the kind of principle. You can start easy and get a ton of value and you can take it to the advanced side of things where you can be doing this in a very enterprise environment. Some of the top orgs in the whole world are maybe using some of these approaches, which is really cool to sort of wrap your head around because PowerShell and VS Code is a tool that will sort of scale with you in your career. Whether you're at a small mom and pop shop kind of cutting your teeth and enjoying things, or you're at maybe a place with a little bit more established procedure, say. Yeah.

One thing I'd add also is PowerShell is awesome with the fact that the AST is available to you extremely trivially. You get it almost out of the box. Where I first learned about ASTs and writing what are called S expressions to the kind of search. It's almost like you can imagine like grep for ASTs was in Ruby and writing chef code. So it was like, okay, here's this thing that has to parse the code and you get something, you get an AST, but it looks very different than the PowerShell. But once you kind of conceptualize what that means, you can kind of carry that into other languages. And PowerShell just does that, makes that very easy to do. Yeah. Like you can actually inspect it very trivially. I

was seeing that. I'm looking forward to jumping into the demo here pretty soon, but I want to give people a little bit more background. So this AST, this abstract syntax tree, from what I saw, and you can kind of clarify where I'm wrong here, it is basically like whenever you have something in PowerShell, it needs to be, I guess, processed by the engine, and it turns into something, and it turns into all this stuff, right? So the AST is sort of your way at seeing the different things that your command actually is, that PowerShell uses in another step later down the road. But in the meantime, you can still see access to a full object. It turns your code into a blown out object with tons of properties. Is that fair? Where am I wrong here? Where can you fill me in?

Yeah, that's probably a good way to describe it. You can imagine that if you look at your PS1 file, it is just text. It's a text document, right? The words inherently don't make the code, right? Something has to read those words, determine that that verb noun is actually a function and has to say, this is what a string looks like. And this is what a flag looks like. Right. And so really you're talking about kind of like the core fundamentals of like how you create a language. And so the AST is basically is like the text was read and then powers shells like here's that as an object. Like now you can go and take a look at this tree and see how was it interpreted, right? Which

is more on the high level end of things. You have to be pretty experienced in PowerShell to be at the point where you're ready to utilize that, I feel. Maybe not super advanced, but at least intermediate. Right out of the gate, you don't need to worry about that. Things happen in the background. PowerShell takes care of it for you. But at any point in time, if you need to leverage some of this additional information, it's already there for you. You just need to know about a certain variable and some properties. And I think we're going to go through some of that here pretty shortly. But yeah, I mean, it's just so cool. I love that how like with this object oriented language, just by running stuff, we get so much added value because to maybe parse things and kind of come up with that on our own would take a very significant amount of coding that I don't really want to do just to solve a little problem. Yeah

and with other languages you did it's like a secondary thing right it's like we made the language we make it run and then somebody else comes by and it's like all right I got to write a to parse that and make the tree. Whereas with PowerShell, you just get it again out of the box. It's like once I realized that.ast existed, it was like with GetMember, I was able to start poking around. It's like, what is that thing? I've never seen that type. What does that mean? And so you start to kind of, you know, start to look under the hood. It's like, it is a little bit of like, we're going to, you know, watch the sausage get made. It's, it's, it's a little terrifying, but, um, but I think once you realize that it's maybe not as scary as it looks, it's, it can be extremely powerful.