Repository navigation
Open
2 / 22 of 2 issues completedOpen
Fix individual commands that do not respect an explicit
$false value passed to a switch parameter#252422 / 22 of 2 issues completed
Copy link
Labels
Issue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productUp-for-GrabsUp-for-grabs issues are not high priorities, and may be opportunities for external contributorsUp-for-grabs issues are not high priorities, and may be opportunities for external contributorsWG-Cmdletsgeneral cmdlet issuesgeneral cmdlet issuesWG-ReviewedA Working Group has reviewed this and made a recommendationA Working Group has reviewed this and made a recommendation
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues.
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
# The *presence* of the switch selects UseWindowsPowerShellParameterSet.
# Irrespective of the switch *value*, CreateRunspacesForUseWindowsPowerShellParameterSet() is called.
# This subverts reasonable user expectation. UseWindowsPowerShell was NOT requested, yet the command
# ignores that request.
New-PSSession -UseWindowsPowerShell:$false
# Likewise, this results in [datetime] output, despite it not being requested.
$params = @{ Since = $false }
Get-Uptime @paramsContext:
This is a continuation of the following issues:
Get-Uptime -Sinceignores an explicit$falsevalue #25015- Treat
-Switch:$falsethe same as omitting a switch when selecting a parameter set #25027
Summary:
- The first issue discusses how
Get-Uptime -Since:$falseis not respected. That is, despite the explicit$falsevalue,Get-Uptimebehaves as if-Sinceor-Since:$truewas specified.- This behavior was deemed erroneous and the issue was labelled
Up-for-grabs.
- This behavior was deemed erroneous and the issue was labelled
- The second issue is a proposal by Michael Klement (@mklement0) for a systematic change that would implicitly fix the
Get-Uptimeissue and other commands that exhibit the same problem.- This proposal was rejected due to backwards compatibility concerns.
- I encountered at least 10 commands shipped with PowerShell that exhibit the same problem when looking into the issue further. See here.
- Per Ilya (@iSazonov) in #25015:
Up-for-Grabs - we should fix all cmdlets in the repo if they implement a switch in wrong way.
List of commands to fix:
-
Get-Uptime -SinceGet-Uptime -Sinceignores an explicit$falsevalue #25015 -
New-Guid -EmptyNew-Guid -Emptyignores an explicit$falsevalue #25276 -
Get-Random -Shuffle-Shuffle:$false not respected in Get-Random #26456 -
Get-SecureRandom -ShuffleRespect -Shuffle:$false in Get-SecureRandom #26460 -
Get-TimeZone -ListAvailable-ListAvailable:$false not respected in Get-TimeZone #26462 -
New-PSSession -UseWindowsPowerShell-UseWindowsPowerShell:$false not respected in New-PSSession #26464 -
Split-Path -Qualifier/-NoQualifier/-Leaf/-IsAbsolute(not-Extension/-LeafBase) -Qualifier/-NoQualifier/-Leaf/-IsAbsolute:$false not respected in Split-Path #26470 -
Test-Connection -Repeat/-MtuSize/-Traceroute-Repeat/-MtuSize/-Traceroute:$false not respected in Test-Connection #26475 -
Where-Object(all non-common switch parameters) -[Operator]:$false not respected in Where-Object #26480 -
ConvertTo-Csv -UseCulture:$falseConvertTo-Csv/Export-Csv -UseCulture:$falseuses the wrong delimiter in ouput #26513 -
Export-Csv -UseCulture:$falseConvertTo-Csv/Export-Csv -UseCulture:$falseuses the wrong delimiter in ouput #26513 -
ConvertFrom-Csv -UseCulture:$false -
Import-Csv -UseCulture:$false -
Get-Culture -ListAvailable:$falseFix Get-Culture -ListAvailable:$false and Get-Location -Stack:$false #27034 -
Get-Location -Stack:$falseFix Get-Culture -ListAvailable:$false and Get-Location -Stack:$false #27034
Request
Fix each command listed above individually, so that explicitly passing a $false value to the specified switch parameter is respected.
Expected behavior
-Switch:$false results in the same behavior as not passing -Switch.
Actual behavior
For the commands listed above, -Switch:$false results in the same behavior as -Switch or -Switch:$true.
Environment data
Name Value
---- -----
PSVersion 7.6.0-preview.3
PSEdition Core
GitCommitId 7.6.0-preview.3
OS Microsoft Windows 10.0.19045
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0, 5.0, 5.1…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Reacted by Michael Klement
Metadata
Metadata
Assignees
Labels
Issue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productUp-for-GrabsUp-for-grabs issues are not high priorities, and may be opportunities for external contributorsUp-for-grabs issues are not high priorities, and may be opportunities for external contributorsWG-Cmdletsgeneral cmdlet issuesgeneral cmdlet issuesWG-ReviewedA Working Group has reviewed this and made a recommendationA Working Group has reviewed this and made a recommendation
Type
Projects
- StatusShow more project fieldsReviewed
Activity
surfingoldelephant commentedon Mar 26, 2025
Ilya (@iSazonov) Are individual issues for each of the affected commands also required? Or will this singular, meta-issue suffice?
[-]Fix PS-shipped commands that do not respect an explicit `$false` value passed to a switch parameter[/-][+]Fix individual commands that do not respect an explicit `$false` value passed to a switch parameter[/+]kilasuit commentedon Mar 26, 2025
Single issues & are linked to this one please. This allows smaller easier to review commits/PR's whilst enabling more than 1 person to work on fixing these issues at a time. It also helps the WG's when reviewing issues/PR's to be able to quickly review them if it's a smaller change.
surfingoldelephant commentedon Mar 26, 2025
Thanks, sounds good. I will link the new issues in the OP as and when they're submitted.
New-Guid -Emptyignores an explicit$falsevalue #25276Get-Uptime -Sinceignores an explicit$falsevalue #25015SteveL-MSFT commentedon Oct 1, 2025
@PowerShell/wg-powershell-cmdlets agree these are bugs
surfingoldelephant commentedon Nov 17, 2025
I've removed
Register-PSResourceRepository -PSGalleryfrom the OP as it pertains to a command in a different repo.Here's the
PSResourceGetissue: PowerShell/PSResourceGet#1805iSazonov commentedon Nov 21, 2025
Are there other cases in our code base for fixing?
surfingoldelephant commentedon Nov 21, 2025
The original list in the OP is based on the testing here. I focused on all mandatory switch parameters belonging to commands shipped with PowerShell.
For non-mandatory, at the very least, we'd need to check parameters that meet the following criteria:
__AllParameterSets.There's 137 parameters that meet that. Checking those would cover the most common cause of the issue (i.e., branching on the parameter set name instead of the switch value).
Parameter list to check:
Code to generate list:
However, it doesn't cover causes of the issue that don't involve parameter sets at all (e.g.,
MyInvocation.BoundParameters.ContainsKey('SwitchParam')). So for completeness, there's a total of 450+ parameters that require checking.Fully automating that will be difficult, I think. Some degree of manual checking (either by searching the code base or testing commands manually) will probably be needed, but naturally it would require substantial effort.
iSazonov commentedon Nov 22, 2025
Too much to fix in a reasonable time. Rather, we should ask - are there any cmdlets where there are very annoying problems with switches?
If we don't know any of them now, then I suggest closing this issue. Users can always open a new one if the need arises.
surfingoldelephant commentedon Nov 22, 2025
I don't necessarily know about annoying, but I did take a cursory look through the list and the following are broken in a similar way to the ones we've already fixed:
ConvertTo-Csv -UseCulture:$false(results in no delimiter at all)Export-Csv -UseCulture:$false(results in space as the delimiter)ConvertFrom-Csv -UseCulture:$false(doesn't parse using default delimiter)Import-Csv -UseCulture:$false(doesn't parse using default delimiter)Get-Culture -ListAvailable:$false(behaves like-ListAvailable)Get-Location -Stack:$false(behaves like-Stack)Format-Hex -Raw:$false(behaves like-Rawand still emits warning)It really depends how far we want to take this.
If
-Switch:$falseshould behave as if-Switchwasn't specified, all commands with switches tied to a distinct parameter set are technically broken. E.g.,Measure-Object,Measure-Object -LineandMeasure-Object -Line:$falseall behave differently (that is,-Line:$falsedoesn't behave like omitting the switch or including-Line).Measure-Objecthas many switches like this split across different sets.New-Object -TypeName int -Strict:$falseshould behave likeNew-Object -TypeName int, but fails because-TypeName/-Strictare in different sets.help's switches.It's probably not feasible/worth it to fix all of the commands like that.
I suggest
ConvertTo-Csv,Export-Csv,ConvertFrom-Csv,Import-Csv,Get-CultureandGet-Locationat the very least should be fixed before closing this issue. I've updated the OP accordingly and filed #26513 as a start.Fix Get-Culture -ListAvailable:$false and Get-Location -Stack:$false
SufficientDaikon commentedon Mar 15, 2026
Submitted #27034 — fixes
Get-Culture -ListAvailable:$falseandGet-Location -Stack:$false. Same if-guard pattern as the 9 previously merged sibling PRs.Fix Get-Culture -ListAvailable:$false and Get-Location -Stack:$false