-
Notifications
You must be signed in to change notification settings - Fork 8.3k
Changes in wildcard expansion logic #6927
Copy link
Copy link
Closed
Labels
Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifResolution-FixedThe issue is fixed.The issue is fixed.WG-Cmdlets-Managementcmdlets in the Microsoft.PowerShell.Management modulecmdlets in the Microsoft.PowerShell.Management module
Milestone
Metadata
Metadata
Assignees
Labels
Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifResolution-FixedThe issue is fixed.The issue is fixed.WG-Cmdlets-Managementcmdlets in the Microsoft.PowerShell.Management modulecmdlets in the Microsoft.PowerShell.Management module
This issue is opened to discuss the change made in #5839 and its possible consequences.
Originally made to fix #5752 (avoid wildcard expansion in working folder path when opening new session), it also has other effects that require more careful evaluation.
(following is the copy of my original comment)
Something with implemented fix still bothers me.
When started playing with v6.1.0-preview.2, I realized that
Get-ChildItemis also affected by this change.And everything else using wildcard expansion now has added complexity - conditional branch with try-catch (what kind of performance overhead it might also have, btw?)
While this might even make it work as expected more times than before, it has an increased level of surprise. It might make issues caused by the use of
-Pathinstead of-LiteralPathto show up less frequently but will make them harder to trace when they finally show up.Using wildcards by default and literal path as an option was a major design mistake, imo. This patch makes a step back, but in a way that makes it less predictable. Is it OK to have more "magic"?
I also wonder why the fix was made in this way instead of just calling
Set-Locationwith-LiteralPathwhen initializing a session? Working folder is by definition a literal path. It would've kept behavior changes to minimum.