`Resolve-Path -Relative`: `-RelativeBasePath` accepts wildcard expressions, reports different results when matched via wildcard

[mklement0]

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

Note:

• I think-RelativeBasePath shouldn't even accept wildcard expressions, so to me the preferable resolution is to simply treat -RelativePath arguments as literal paths. (Currently, a wildcard is accepted, but only if it resolves to exactly one item).

  • There is precedent for making such a - technically breaking - change, e.g the -OutFile parameter of Invoke-WebRequest and -InvokeRestMethod, which used to accept wildcards, but now interprets paths literally - see Make -OutFile param in web cmdlets to work like -LiteralPath #11701 (comment)

• Doing so would make the problem at hand go away; if this is decided against, at least the inconsistency below must be fixed.

# Matching with *literal* path.
Resolve-Path System32 -Relative -RelativeBasePath C:\Windows

# Matching the same path *via wildcard*
Resolve-Path System32 -Relative -RelativeBasePath C:\Window[s]

Expected behavior

.\System32
.\System32

Actual behavior

.\System32
..\Windows\System32

That is, even though in both commands C:\Windows was ultimately used as the base path, the wildcard matching resulted in different output.

Error details

No response

Environment data

PowerShell 7.4.0

Visuals

No response

[iSazonov]

@mklement0 I can not reproduce your example with completion with 7.5 and later. Can you confirm and update the issue?

[mklement0]

@iSazonov, this issue isn't about tab completion, it's about unexpected output, and the repro in the initial post still works for me in v7.5 and v7.6.0-preview.4