Understanding $args in PowerShell

scottalanmiller

@Martin9700 ah yes, you can reference the array itself as a whole rather than the individual elements. Makes sense.

Martin9700

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"

scottalanmiller

@chutestrate said:

Well, I"m just not going to get this easily. I'm getting singular concepts but it's not flowing together cohesively.

Try actually running the script that I just made where it takes an unlimited number of arguments, stores them in the $args array and prints them out one at a time. Play with that for a minute actually running it with different arguments passed it. I think that it will help once you see it a few times.

scottalanmiller

@Martin9700 that makes learning it so much harder though. If a single array is confusing, doing that makes it even more abstract.

chutestrate

which script the args or param

Martin9700

@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.

Martin9700

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

scottalanmiller

@chutestrate said:

which script the args or param

Using param to abstract args is going to make learning what an array is less simple.

scottalanmiller

@Martin9700 said:

@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.

That's much more complex because you are using a more complex structure where you now have to have names. It is easier to use when you are dealing with arbitrary inputs, but that isn't the goal here. John is trying to understand what an argument is and what an array is.

Martin9700

@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.

chutestrate

Sorry martin9700 I'm not even close to understanding what you are trying demonstrate.

scottalanmiller

Here is a slightly more complex example but it gives more illustrative output.

for ($i=0; $i -lt $args.length; $i++) {
  'This is $args[' + $i + "], which is: " + $args[$i]
}

Save and run with any number of arguments that you want.

> .\argsdemo.ps1 I can put in a lot of arguments and it works just fine for a demo.
This is $args[0], which is: I
This is $args[1], which is: can
This is $args[2], which is: put
This is $args[3], which is: in
This is $args[4], which is: a
This is $args[5], which is: lot
This is $args[6], which is: of
This is $args[7], which is: arguments
This is $args[8], which is: and
This is $args[9], which is: it
This is $args[10], which is: works
This is $args[11], which is: just
This is $args[12], which is: fine
This is $args[13], which is: for
This is $args[14], which is: a
This is $args[15], which is: demo.

scottalanmiller

@chutestrate said:

Sorry martin9700 I'm not even close to understanding what you are trying demonstrate.

Martin is correct, that trying to tackle $args when you don't have a solid understanding of everyday arrays first is going to be confusing.

Martin9700

@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.

scottalanmiller

Oh, I have an idea.

Think of my way of doing $args as being like MadLibs. But you just give a string of words and they get put in in order. Your program or script is like a MadLibs where you feed it the list of words and it says funny things. In fact, making an actual MadLibs script is a common and fun scripting project to do for exactly this reasons.

Now Martin's way is more like MadLibs where you know some basics like name, age, color, size, etc. and you put in words associated with those things so that you get a simpler matching of words to where they are used.

The approach that I am demonstrating is just taking things in order one after another. His is to identify what they are and label them so that they are more useful. Both are important to understanding, but one after another. In the real world of script writing his approach is way, way more common and practical. Not every single time, but the vast majority. But understanding my way first is important because you need to know what is happening.

Martin9700

@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])"
}

scottalanmiller

That's a little better I'm a BASH, Python and Ruby guy, I don't really write PowerShell normally

chutestrate

You guys are right about needing to understand arrays better i guess. I just started this last week, and thought i had at least a slight understanding of it. I can follow the scripting commands in the first line, but what is the second line doing?

At least i can make ps1 files, and get it into powershell, lol

scottalanmiller

@chutestrate said:

I can follow the scripting commands in the first line, but what is the second line doing?

The second line is just printing out the name of the argument that we are on and what the value of that argument is for you to see. When you look at the output you can see it patch up. You get to see the name of the argument like $args[0] and the value held by that argument.

scottalanmiller

An array, as we discussed via PM, is an "array of things", like a list. As we are programming here, that is really a list of variables. So in the same way that a normal variable can have something in it such as a string, so can an individual array element. Here is an example:

$myname = "John"

or as a single element array:

$myarray[0] = "John"

These two things accomplish basically the same thing. You have stored your name in a variable. Now what if we want to store a second name?

$yourname = "Peter"

or as part of the array that you already made:

$myarray[1] = "Peter"

Again, we did the same thing. But to work with the plain variables we need to know two variable names. To do the same thing with the array we need only know one array name. Doesn't make much difference when we have only two. But what if we had ten, or a hundred, or an indefinite number of names to store? Then an array because way, way easier to manage because it can be of arbitrary size holding just one name or thousands.

Each has its place, but arrays are a very important way to hold data in a program.