Parameters used interactively should be validated immediately and allow/require the user to provide valid input. That is what the user must do anyway.
It would be helpful if parameter validation would lead the interactive user to success sooner rather than later.
The following script requuires a two (2) valid paths. If the paths are entered interactively, the user does not know of a failed validation until after ALL parameters are entered.
PS C:\src\t> Get-Content -Path '.\parammessage.ps1'
[cmdletbinding()]
Param (
[Parameter(Mandatory=$true, HelpMessage='Enter a valid path 1')]
[ValidateScript({ Test-Path $_ })]
[string]$Path1
,[Parameter(Mandatory=$true, HelpMessage='Enter a valid path 2')]
[ValidateScript({ Test-Path $_ })]
[string]$Path2
)
Write-Host "+++$Path1==="
Write-Host "+++$Path2==="
PS C:\src\t> ($PSVersionTable.PSVersion).ToString()
7.0.0-preview.3
PS C:\src\t> .\parammessage.ps1
cmdlet parammessage.ps1 at command pipeline position 1
Supply values for the following parameters:
(Type !? for Help.)
Path1: asdf
Path2: C:\
C:\src\t\parammessage.ps1 : Cannot validate argument on parameter 'Path1'. The " Test-Path $_ " validation script for the argument with value "asdf" did not return a result of True. Determine why the validation script failed, and then try the command again.
At line:1 char:1
+ .\parammessage.ps1
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [parammessage.ps1], ParameterBindingValidationException
+ FullyQualifiedErrorId : ParameterArgumentValidationError,parammessage.ps1
What I would like to see is the interactive prompt use the HelpMessage specified and give the user an opportunity to enter valid information if needed.
PS C:\src\t> .\parammessage.ps1
cmdlet parammessage.ps1 at command pipeline position 1
Enter a valid path 1
Path1: asdf
Entry is not valid.
Enter a valid path 1
Path1:
If the entry for Path1 is not valid, the script will fail. I do not see benefit in requiring ALL parameters to be entered before informing the user that one will not pass validation.
Looks good but I see one problem for UX because there might be a delays (ex.: cloud request) that is very bad for UX in interactive sessions.
@iSazonov - I would like to understand better how delays would pose a problem for this change. I think of "delay" in remote (cloud) requests via UX (User Interface) as either communication link latency or waiting for the user's brain to signal a finger to press down. Please help me to understand better. Thanks.
My concern is that users may experience delays if we will call validates every time a key is pressed (especially if the attribute makes a remote request).
@iSazonov - I was not suggesting validation on every keystroke. I was suggesting validation after the value is entered and the Enter key is pressed.
So you mean when a command has mandatory parameters that are not provided by a user, resulting in individual prompts for the mandatory parameters, PowerShell should perform parameter validation on the values entered at the prompt when they are entered, and re-prompt the user for the parameter if they provided a value that is invalid, to guide users toward a path of successful invocation? That makes sense to me.
@Liturgist Please update your issue description.
@iSazonov - Does the new description reflect what you are suggesting? If not, please tell me more explicitly what should be changed. Thanks.
So you mean when a command has mandatory parameters that are not provided by a user, resulting in individual prompts for the mandatory parameters, PowerShell should perform parameter validation on the values entered at the prompt when they are entered, and re-prompt the user for the parameter if they provided a value that is invalid, to guide users toward a path of successful invocation? That makes sense to me.
Yes, @KirkMunro. And the HelpMessage
text should be used to prompt the user for the value.
@Liturgist Thanks!
It seems the enhancement is easy to implement. Do you want to grab this?
@Liturgist Thanks!
It seems the enhancement is easy to implement. Do you want to grab this?
@iSazonov - I would love to do it, but I have never done a github change before. It might be a long time before I got it working. I am solid (many years) on C, ok on C++, and newbie to C#. What would I face? I only have Visual Studio community edition. Can it be done with that? I also have Linux machines. What toolset is needed on Linux?
I think my first step is to gather the infrastructure and configuration and see if I can build something that works without making any change.
@Liturgist You need to read our contribution docs in the repo. Perhaps they is old. It would be great if you pulled PRs with your new acquired experience - this also will train you to create PRs and to works with Git.
Install PowerShell Core, VS Code with recommended plugins and latest .Net Core 3.0.
@Liturgist If it helps, I can make myself available to help, either via answering direct questions, having a conference call with screen share to help you through the process, or even doing a live stream via Twitch (I'm getting set up for that, but may switch to LinkedIn if they give me access to their live streaming service before I get set up).
Also to keep in mind since you are interested in doing this: October is Hacktoberfest, an annual event that promotes open source contributions where you can be rewarded (t-shirt, stickers, etc.) if you contribute a certain amount during the month of October (other years it has required 5 PRs -- they can be any PRs, docs changes even, and they don't need to be accepted/merged in, just submitted during the month of October). It's a lot of fun if that sort of thing interests you.
@KirkMunro - I am going to re-read the contributing doc. When I tried to open the .sln in VS 2019 it reported two (2) problems. I probably do not have something setup correctly.
The doc I read said VS 2015. Is that an absolute requirement. Can I use VS 2019 successfully?
@Liturgist VS 2015 is not an absolute requirement. I only use VS 2019.
One tip I'll share that works very well for me: I use VS 2019 only for editing files, because I like VS as an editor. I use PowerShell and the ./build.psm1
module for building PowerShell. Using PowerShell for the build process allows you to leverage all of the command-line work that has already been done.
The easiest way to get going IMHO is to fork the repo, clone it, create a new branch for whatever changes you want to work on, import the build.psm1
module, invoke Start-PSBootstrap
from your PowerShell folder, then invoke Start-PSBuild
from that folder. Once you have it built at least once, _only then_ do I open the solution in Visual Studio for file editing.
@KirkMunro - I sent a message to you on poshoholic.com since this may not be the right place for this kind of discussion.
Many thanks to @KirkMunro and @iSazonov. I finally got to where I could build and have found my way down to .\src\Microsoft.PowerShell.ConsoleHost\host\msh\ConsoleHostUserInterfacePrompt.cs.
Most helpful comment
Many thanks to @KirkMunro and @iSazonov. I finally got to where I could build and have found my way down to .\src\Microsoft.PowerShell.ConsoleHost\host\msh\ConsoleHostUserInterfacePrompt.cs.