Parameters and Prompts

When you want the best (or worst) of both worlds…

Words: 929

Time to read: ~ 5 minutes

TL;DR: Create a wrapper function that calls your properly constructed one. 🙂

Update: 21-Sep-2018 – u/Ta11ow and u/Lee_Dailey brought up two succinct points about using Read-Host as default parameters and the more appropriate method would be to create a “wrapper” function over the parameter function.
Also created a TL;DR.

Recently, I have been working together on a script with an co-worker who isn’t technically minded.

The reason why is because automation isn’t just hitting the I.T. sector, people from all over are realising that there are more convenient ways of accomplishing tasks.

However, there was an inherent difference in how my co-worker saw automation and how I saw automation.

They saw it along the lines of:

Automation will bring me to exactly where I need to go so that I can do what I’m supposed to do.

Whereas I saw it more along the lines of:

Automation will do exactly what I ask it to do; removing me from the equation so I can work on other tasks.

To this very moment I’m still not exactly sure who is right and, if we are both right then, who is more right. (that’s important between us 🙂 ).

What they want: Prompts

Prompts for automation

This is the automation that they are talking about; step by step guide where, rather than you use parameters, you get prompted for the input.

In case you are wondering what the deal is with all the do...until blocks, it’s quite difficult to introduce parameter validation so this is my attempt at doing so.

Case in point…

We’re going to keep doing this until you get it right…

What I want: Parameters

It works!

Now, it may be just because I’m used to this way but I like it more. We can pass in the parameters at the very start which we couldn’t do with prompts…


…and validation is built in for us when we use the ValidateSet, ValidateRange, and ValidateScript attributes…

1. Script 2. Range 3. Set

but what about the help? How are we going to know what we’re supposed to put in there? ‘Path’, ‘Number’, and ‘Set’ could mean anything!”

Not a problem, we can just run it again and, when we’re prompted for a value, we can just write “!?”…

“!?” for help

As you may have guessed…

…this did not go down well with my co-worker.

That?! How are we supposed to know to write “!?” there? How does that even mean help anyway? Can we not just get the help message to show up on it’s own!

To which I said…

We can but it’s going to create a massive bottleneck! If we try and put in the help messages then it’s going to slow things down eventually because we’re not going to be able to run this without someone babysitting it! Do you want to be the person that has to sit there watching this every single time it’s run?

Compromise is a wonderful thing though and we eventually managed to merge the best of both worlds…

What we got: Parameters and Prompts

Prompts, Parameter, and…party?

Thanks to the joy that is $PSBoundParameters (Get-Help about_Automatic_Variables | Select-String -Pattern 'PSBoundParameters' -Context 0,5)[0]) we can tell when a parameter is passed in, and prompt for it when it’s not.

Contains a dictionary of the parameters that are passed to a script
or function and their current values. This variable has a value only
in a scope where parameters are declared, such as a script or function.
You can use it to display or change the current values of parameters
or to pass parameter values to another script or function.

This way we can include full automation without the need for baby-sitting while allowing helpful prompts to be displayed for any users not trained in the function.

A great addition is that the prompts still respect the Validation that we did in the param() block!

All the Validation!


Update 21-Sep-2018

It was pointed out to me on the PowerShell Reddit forum (if you’re not on there already sign up, even if it’s just for notifications of trending posts. I cannot begin to explain how much I’ve improved from there) that a potentially easier method for this would be to make the default value of a parameter be Read-Host.

As you can see it works perfectly:

So much simpler!

An even better idea though, was when they said that recommended practices would be to create a wrapper function. That way you can have your properly constructed function, with validation, verbose comments, confirmation messages, etc nicely separated from their semi-manual process.

Plus it’s so much sneakier which, I’m not going to lie, appeals to me on some level 🙂

That way, my co-worker can call this function while I happily automate it away with Test-Parameters.

Like a snickers bar, it’s got a wrapper (bad joke intended)

I’m liking this!


…if an aspect is in the way, and it’s an obvious and easy task to remove it that won’t cause issues down the line, then why not just remove it?

This way we have a way that keeps both parties happy; my co-worker with his prompts and me with my parameters.

I’ll take that.


I do most of my coding in VSCode now and found a lovely little bug in the PowerShellEditorServices.

No help for you, you play the game on extreme difficulty.

See it? No “!?” option for help.

Added a bug report here so if smarter people than me want to work on that, it’d be much appreciated.

Thank you!








Author: Shane O'Neill

DBA, T-SQL and PowerShell admirer, Food, Coffee, Whiskey (not necessarily in that order)...

2 thoughts on “Parameters and Prompts”

What's your opinion?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s