Remove-IISConfigCollectionElement -Confirm Parameter Documentation Does Not Match Behavior
Opened this issue · 0 comments
Prerequisites
- Existing Issue: Search the existing issues for this repository. If there is an issue that fits your needs do not file a new one. Subscribe, react, or comment on that issue instead.
- Descriptive Title: Write the title for this issue as a short synopsis. If possible, provide context. For example, "Typo in
Get-Foo
cmdlet" instead of "Typo." - Verify Version: If there is a mismatch between documentation and the behavior on your system, ensure that the version you are using is the same as the documentation. Check this box if they match or the issue you are reporting is not version specific.
Links
Summary
The behavior of the Remove-IISConfigCollectionElement
's -Confirm
parameter does not match the documentation.
The documentation can be interpreted as: in absence of the -Confirm
parameter, the Cmdlet will execute without interactive confirmation being required.
In my usage of the Cmdlet, I was required to pass -Confirm:$false
to bypass interactive confirmation. This does not match the documentation.
Default value: False
Details
Examples
This snippet calls the Cmdlet without the -Confirm
parameter being passed
Remove-IISConfigCollectionElement -ConfigCollection $IISConfigCollection -ConfigAttribute @{ 'name' = $CustomHeader.Name }
Result in non-interactive mode
Remove-IISConfigCollectionElement : Windows PowerShell is in NonInteractive mode. Read and Prompt functionality is not available.
This snippet calls the Cmdlet with the -Confirm
parameter being explicitly set to the documentation's default value ("$false")
Remove-IISConfigCollectionElement -ConfigCollection $IISConfigCollection -ConfigAttribute @{ 'name' = $CustomHeader.Name } -Confirm:$false
Result in interactive and non-interactive mode
No errors, and the Cmdlet is successfully executed without a prompt and behaves as expected.
Suggested Fix
Change the default value in the -Confirm
parameter's Default value to True or raise an issue with the PowerShell team if the Cmdlet is not behaving per specifications.