Do you use Read-Host to receive user input? If you do, rethink. Read-Host always prompts a user, and there is no way to automate scripts that use Read-Host:
$City = Read-Host -Prompt 'Enter City'
A much better easy way would look like this:
This creates a mandatory parameter. If the user does not supply it, a prompt is created, very similar to Read-Host. Yet, the user can always submit the parameter to his script and automate it. Just make sure there is only one param() statement, and that it is at the beginning of your script. Use commas to separate multiple parameters.
And if you don’t like the standard prompt produced by param(), check out this:
$City = (Read-Host -Prompt 'Enter City')
Here, you have full control over the prompting, yet the user can again submit the argument via parameter, and run the script unattended.
ReTweet this Tip!
I also meant to add that if you want to use Read-Host and take the parameter approach.
You can use both at the same time. There is a post on this site titled...
"Read-Host Blocks Automation"
... that shows you how it is done.
The author is not saying this eliminate interaction, but advances automation efforts. All CLI, and GUI require interaction. This is just how cmdlets work normally.
If you take a step back away form PoSH for now and think Windows OS installs (client and server).
Sure, you can use the GUI to install them and manually answer every question, think, Read-Host and dialog boxes here, but you can also create silent / automated installs using .INF files and other deployment tools.
Now, had a laptop to a user, boot it up and it auto installs, with the exception of he user have to enter their network creds at the end, there is no user interaction until then, while all else is automated.
Coming back to PoSH. Ask yourself a question. If every time you got a Read-Host prompt from every parameter in every cmdlet, that would get old really quick.
read-host -Prompt 'enter the name of the item you want like to create'
read-host -Prompt 'enter the path where the item is to be stored.'
...vs, just doing..
new-item -Name 'test.txt' -path $env:USERPROFILE\Documents
So, for AD cmdlets, you'd see this a dozen times, vs just providing it all up front.
The author is just encouraging you to create script, functions, cmdlets, modules, so that they work the way native cmdlets work.
I'm sorry, but this newbie doesn't quite understand how this makes a difference. How does this obviate the need for interaction?