Ensure that actually existing paths are processed literally #26585
Conversation
Literal processing path to avoid misinterpreting wildcards
|
From previous investigations it is not full fix. |
Added suppression of wildcard expansion for history paths.
Avoid incorrect results caused by the different slash directions of path separators on different operating systems.
Updated the ResolvePathCommand to treat the base path literally and suppress wildcard expansion during path resolution.
There was a problem hiding this comment.
Pull request overview
This pull request fixes issues #25282 and #20701 where PowerShell incorrectly interprets wildcard characters (particularly square brackets) in file paths when using Set-Location with history navigation (Set-Location - or Set-Location +) or when switching between drives using drive letter shortcuts (e.g., C:, D:).
Key Changes
- Modified
SessionStateLocationAPIs.csto suppress wildcard expansion when retrieving paths from location history - Updated
InitialSessionState.csto use-LiteralPathparameter in the default drive-switching function - Enhanced
ResolvePathCommand.csto handle theRelativeBasePathparameter as a literal path - Added comprehensive test coverage for wildcard paths in location history
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
src/System.Management.Automation/engine/SessionStateLocationAPIs.cs |
Adds context.SuppressWildcardExpansion = true before Undo/Redo operations to treat history paths as literals |
src/System.Management.Automation/engine/InitialSessionState.cs |
Changes default drive function to use -LiteralPath parameter instead of the positional Path parameter |
src/Microsoft.PowerShell.Commands.Management/commands/management/ResolvePathCommand.cs |
Updates RelativeBasePath handling to process it as a literal path and sets wildcard suppression when changing location |
test/powershell/Modules/Microsoft.PowerShell.Management/Set-Location.Tests.ps1 |
Adds new test case for wildcard paths in history navigation and adds -ErrorAction Ignore for consistency |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
src/Microsoft.PowerShell.Commands.Management/commands/management/ResolvePathCommand.cs
Outdated
Show resolved
Hide resolved
…nt/ResolvePathCommand.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Add tests for Resolve-Path with wildcard characters in RelativeBasePath
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days. |
PR Summary
Fix #25282
Fix #20701
Fix #20931
Literal processing actual path to avoid misinterpreting wildcards
PR Context
Incorrectly interpreting wildcards in the history path
If you have two file drives, and you first enter a folder with a path containing “pwsh wildcards” (mainly square brackets), then switch to another drive and switch back, pwsh will incorrectly interpret the wildcards in the path, resulting in an error.
For example, if you are currently in a folder with the path
C:\pwsh[net10], and then you typeD:and press Enter, followed by typingC:and pressing Enter, you will be able to observe this error.Using
Set-Location +orSet-Location -to navigate through history has the same issue: if any previous path contains PowerShell wildcards, an error occurs when trying to switch to it.Incorrectly interpreting wildcards in the relative path twice in succession
the
Resolve-Pathcommand behaves similarly when handling paths. The specific reason is thatResolve-Pathresolves wildcards twice for the path passed via-RelativeBasePathand then navigates to the resulting location. If the path itself contains wildcards, it cannot be resolved correctly.PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright header