Getting Microsoft and MSP's to come visit once is pretty cool, but there's almost no content here for those people. There's ZERO Enterprise level content from a Microsoft basis. Frankly I get a bit of a anti-Microsoft vibe here. How do you plan on getting these people to do more then a single visit, look at a few posts and never come back?
Posts made by Martin9700
-
RE: February 13th (Friday) - MangoLassi Day!
-
RE: What Code Repository Service Do You Use?
Nothing right now but we're going to trial Team Foundation Server in the next couple of weeks. It's about the only repo that's integrated with PowerShell ISE's.
-
More PowerShell Goodness...
If you love reading about improving performance in PowerShell (which admittedly isn't its strong suit) then you'll love these two posts. First one:
http://thesurlyadmin.com/2015/01/26/dynamic-fields-in-objects-what/
sets the stage. I talk about creating an object where the properties can update dynamically based on values in other properties of the object. It's THIS close to class, without the persistence or reusuability. And then with a little playing we discovered how cool this technique could be:
http://thesurlyadmin.com/2015/01/27/dynamic-properties-in-objects-and-performance/
-
RE: PowerShell.org announces it's 2015 Hero's
@scottalanmiller said:
Cool. Were not people that I was aware were so active in PowerShell.
Bob has been super active over at PowerShell.com for awhile and came to Spiceworks about 6 months ago. Craig has been active a bit longer on Spiceworks.
-
PowerShell.org announces it's 2015 Hero's
Couple of SpiceHeads (don't think either are here on Mango) just got recognized as 2015 PowerShell Hero's by PowerShell.org! Come congratulate them
http://community.spiceworks.com/topic/744795-powershell-org-announces-its-powershell-hero-s-for-2015
-
Latest Blog Post: Shrink MS SQL Log Files with PowerShell
http://thesurlyadmin.com/2015/01/05/shrink-sql-log-files/
Since it's all about self-promotion, figured I'd put this out there to see what happens. Let me know what you think.
-
RE: I am defeated
@nadnerB said:
I've started getting into PowerShell, granted most of my scripts consist of copy, paste and "OMGWTFBBQ! WHY YOU NO WORK!?", I am getting there... slowly
Hey, you never really leave that state, I'm afraid.
@cakeis_not_alie said:
@Martin9700 Sounds nice. Except for the part where I am a sucky little GUI baby and not overly fond of PowerShell.
Which seems odd if you're trying to do automation and NOT spend tons of money. So many things you can do with PowerShell! We have 2 dedicated servers at my work that ALL they do is run PowerShell scripts (maybe 1 old VBS)!
-
RE: I am defeated
Need to come hang out in the PowerShell forum. Our troll quotient is almost zero except for a European complaining about date formats
I think we've managed to maintain the old school Spiceworks feel. But we're small, maybe that's the key.
-
RE: Self healing applications with Salt
Funny story. In our change control meeting a couple of weeks back, one of our Systems Engineers had a ticket in for deploying Salt minions. The guy running the meeting is the manager of the NOC and he read the ticket off, then suddenly sat up straight and looked around... "OK, you guys are just messing with me now..."
Funny geek humor. But the way he said it cracked up the whole room.
-
RE: Directory Tree Depth: Report
This is actually a problem in PowerShell too because it has the same 256 limit!! Which I just don't understand why this hasn't been permanently fixed--problem has only been around for a decade or so!
Anyway, to accomplish in PowerShell the best bet is to use Robocopy to just list the directories, then it's child's play to get the lengths > 256 and display. It's the Robocopy that's a pain, luckily:
http://thesurlyadmin.com/2014/08/04/getting-directory-information-fast/
Not exactly on topic, but it has the code for building an array with the data in it.
-
RE: Understanding $args in PowerShell
Let me take a stab at explaining an array. It's just a list. When you write your groceries on a piece of paper you have a variable with multiple values on it. You don't write a single item per piece of paper, right? If you did that'd be a regular variable. Instead you put the whole list on one piece of paper, making it an array/list.
Computers are great with lists, but they have some limitations, and they have to be told to do things in a very literal sense. So, grocery list is:
$GroceryList = "beer","wine","whiskey","brandy","vodka","chips"
In PowerShell, the comma's are what tell PowerShell that this is an array. Now, if I ask you what's the 3rd item in the list, you would scan through and count each one, until you got to "whiskey". PowerShell is the same way, but we can jump straight to the third item. Try:
$GroceryList[3]
The brackets with the number tell PowerShell that you want to reference a particular item in the array. The number tells you which item. So we got Whiskey, right? If you tried it, you know we got "brandy". WTF? In programming languages, and this is pretty much universal, arrays always start at zero. So $GrocyerList[0] is beer, $GroceryList[1] is wine, and last $GroceryList[2] is whiskey. So when working with arrays you'd really want to:
$GroceryList[2]
To have PowerShell return the 3rd element. Each item in an array is called an element, by the way. Looking back at Scott's code, what he was doing was creating a For/Next loop, which is a loop using a number as reference.
for ($i = 0; $i -lt $GroceryList.Count; $i ++)
Is some goofy looking stuff, but the first part $i = 0 marks our starting point. $i = 0. The next part is a IF statement, that as long as it's true we'll continue the loop. In PowerShell we have built in properties, and one of those is Count which tells us the number of elements in the array. So as long as our $i variable is less then that count, we'll keep looping in the for loop. The last part $i ++ tells the loop, that when I'm done with the loop add one. The ++ thing is basically shorthand for $i = $i + 1.
Now PowerShell will continue to run the code contained in the scriptblock (all the code between the curly brackets) until our $i variable equals or is greater than the number of elements in our $GroceryList. So the first time through the loop $i = 0, we display that number, and we reference the element in our array that corresponds with zero. Which is beer. Loop ends, $i increments to 1, start again.
Loop displays the number 1, and shows the $GroceryList element that corresponds to that number, which happens to be "wine". Code block ends, $i increments to 2. This is still less the $GroceryList.Count (which is 6, btw) so the loop repeats. Onward until $i get's to 6, at which point it exits the loop and continues on with the script. In this case there is no more script, so it exits the script and drops you back into the shell.
-
RE: Understanding $args in PowerShell
@scottalanmiller said:
I doubt that Martin will agree but I don't find PowerShell to be particularly well suited to learning programming concepts. It's a great language for what it is, but I'm very glad that I learned programming on other languages and then learning PowerShell.
The languages I've mostly worked with are batch/cmd, Visual Basic, vbScript and PowerShell. So PowerShell is a vast improvement over those
It took me awhile to really grasp the idea of objects and using them for everything in PowerShell, but once I did the whole language opened up to me and I began to realize all the things I could do.
-
RE: Understanding $args in PowerShell
@scottalanmiller said:
for ($i=0; $i -lt $args.length; $i++) {
'This is $args[' + $i + "], which is: " + $args[$i]
}This could also be written:
for ($i=0; $i -lt $args.length; $i++) { "This is `$args[$i], which is: $($args[$i])" }
-
RE: Understanding $args in PowerShell
@chutestrate said:
Sorry martin9700 I'm not even close to understanding what you are trying demonstrate.
LOL, which is Scott's point.
I'm not a fan of using $Args because I always preach (and you can check the PowerShell forums over at Spiceworks to back this up) that I always write scripts for the next guy and using $Args in code make it very hard to decipher what the original writer is trying to do. Named parameters are self documenting (assuming you are using meaningful variable names). But to Scott's point, they are a more advanced technique.
-
RE: Understanding $args in PowerShell
@scottalanmiller said:
@chutestrate said:
which script the args or param
Using param to abstract args is going to make learning what an array is less simple.
OK, now I see where you're going with this. I suppose that's an argument, but in my view you should know what an array is and how to manipulate it before you start messing with $Args. Otherwise your picking a tough path to walk. Besides, learning best practices early instead of breaking bad habits later.
-
RE: Understanding $args in PowerShell
And once you get into named parameters, you can start using the parameter decorators:
Param ( [ValidateSet("Martin","Scott")] [string]$First, [ValidateSet("Martin","Chutestrate")] [string]$Second ) Write-Host "Hi $First and $Second!"
Try .\test.ps1 -First Rob -Second Scott
-
RE: Understanding $args in PowerShell
@scottalanmiller said:
@Martin9700 that makes learning it so much harder though. If a single array is confusing, doing that makes it even more abstract.
Then using named parameters? I don't see how that's more confusing then some nameless value you HOPE is right. In this example you have two ways you could run the script:
.\test.ps1 Scott Martin
or
.\test.ps1 -First Scott -Second Martin
Notice in the second example the script is now resembling a proper cmdlet.
-
RE: Understanding $args in PowerShell
@chutestrate said:
Well, I"m just not going to get this easily. I'm getting singular concepts but it's not flowing together cohesively.
It's important to remember though, in PowerShell no one uses $Args. We use named Parameters, just so we can avoid the confusion of $Args. Also makes the script easier to read:
Param( [string]$First, [string]$Second ) Write "Hi $First and $Second"
-
RE: Understanding $args in PowerShell
@scottalanmiller said:
To use the argument that I passed in, the program has to reference it. The only way to reference it in the script is to use $args[0] which is a reference to the first argument passed. If you don't use $args[0] the argument will be ignored as nothing in the script looks for it.
That's not accurate, actually. PowerShell very much will try to display it as best it can. So if you do:
.\test.ps1 Scott
And your script is
Write-Host "Hi " $Args
It'll work just fine. If you run it: .\test.ps1 Scott,Martin you'll get:
Hi Scott Martin
Notice no comma, PowerShell is just squashing the array together. Change the script to:
Write-Host "Hi " $Args[1] " and " $Args[0]"
And run it: .\test.ps1 Scott,Martin and you'll get:
Hi Martin and Scott